Forum OpenACS Development: Providing a patch and the /register/ maze

1: Providing a patch and the /register/ maze

Posted by Tom Jackson on 03/21/02 09:01 PM

I am putting togeather a system where I require admin approval of all users, and I want to provide random passwords for users who loose theirs. I have the following settings in Main Site Parameters:

EmailForgottenPasswordP 1
EmailChangedPasswordP   0 (only applies to admin changing password)
UseCustomQuestionForPasswordReset 1
EmailRandomPasswordWhenForgottenP 1
RegistrationProvidesRandomPasswordP 1
RegistrationRequiresEmailVerificationP 1
RegistrationRequiresApprovalP 1
EmailRegistrationConfirmationToUserP 1

With this setup, I have discovered a number of bugs, which I have fixed, and a few which are just annoyances, which I have not fixed.

The first problem, I reported as a bug in SDM, has to do with user-new skipping the password and password_confirmation form vars in the case of RegistrationProvidesRandomPasswordP being 1, while non-null values are required to submit the form to user-new-2. I simply added different dummy values for these as hidded fields.

The second problem was that apparently NULL used to represent the 'needs approval' state. When a user registers with the current system, 'needs approval' gets inserted into the member_state field. Later pages in the logic assume NULL as the member_state value, and so nothing works.

The annoyances are that when you finish registering, you get an email to verify your address, but once verified, you still do not have a random password to login. You have to first try to login and then have the system send you a new random password.

My main question is: how do I provide a single patch for the 4-5 files I needed to change to fix the problem? Also any suggestions on the best way to fix the annoyance?

2: Response to Providing a patch and the /register/ maze (response to 1)

Posted by Rafael Calvo on 03/22/02 02:40 AM

Tom, is this related to the bug I reported here?

3: Response to Providing a patch and the /register/ maze (response to 1)

Posted by Don Baccus on 03/22/02 03:14 AM

Tom ... just concatenate your diffs into one file, that's fine, run diff from the "packages" directory and patch will find all the files correctly when I run it.

I want to add the fixes to our 4.5 branch because it's important to fix before final release.

As far as the annoyance goes ... we could include the random password in the confirmation e-mail, right? I suspect it would require jacking around the code a bit to get this to work, though. If you want to tackle this, that would be great but I'd ask you to submit it separately from the outright bug fixes. I'd apply that patch to our development branch rather than the release branch ...

4: Response to Providing a patch and the /register/ maze (response to 1)

Posted by russ m on 03/25/02 02:51 AM

oops - the "needs approval" thing would be my bad...

up untill not too long ago member_state was set to NULL for
accounts that needed approval, but that broke
[ad_registration_finite_state_machine_admin_links] which
assumed that they'd be "needs approval". Just changing back to
NULLs will re-break the user admin pages. Everything needs to
settle on one or the other, and I'd lean towards "needs approval"
rather than NULL for consistency with how the other member
states are represented.

Where else in the registration process is NULL used to mark
users who need admin approval? I ran through a couple of
registrations before submitting the patch that made things as
they are now and it all semed to work fine...

5: Response to Providing a patch and the /register/ maze (response to 1)

Posted by Tom Jackson on 03/25/02 05:26 PM

The patch I provided in the SDM patches several files that fixes the sign up process, I settled on 'needs approval' as it seemed more explicit than NULL. The working patch is here: https://openacs.org/sdm/one-patch.tcl?patch_id=213.