LT has to use the "Require e-mail verification when a visitor creates an account" setting from core to make it's decisions, because it leverages the core login block. however, core's idea of email verification and LT's idea of email validation are pretty much polar opposites, which makes this setting very confusing to configure correctly for LT to function properly.
currently, we mirror the setting as 'Set password' in the LT settings, and flip it's display from the core setting, which makes a lot more sense for the way LT works. This however still leaves the core setting at admin/user/settings displayed, which still results in confusion.
all that to say that i think it would be a good idea if we did some form_alter magic at admin/user/settings to remove that checkbox, replace it with a static form value for the setting, and display something like "Control for user set passwords at registration has been moved to the Logintoboggan settings page as the 'Set password' option"
Comment | File | Size | Author |
---|---|---|---|
#6 | disable_core_validation.patch | 1.33 KB | sbrattla |
#4 | hide_vore_validation_01.patch | 1.46 KB | sbrattla |
#2 | hide_core_validation.patch | 1.45 KB | sbrattla |
Comments
Comment #1
hunmonk CreditAttribution: hunmonk commentedplease see http://drupal.org/project/logintoboggan#commitment for more information on how task/feature requests are handled in the module.
Comment #2
sbrattla CreditAttribution: sbrattla commentedHi,
I thought that was a good idea. I've attached a patch which simply adds a little code to logintoboggan_form_alter and modifies the 'user_admin_settings' form. The checkbox 'Require e-mail verification when a visitor creates an account.' simply gets disabled, and the description explains that LoginToboggan now controls this functionality.
Not sure if there are any pitfalls around here, but if LoginToboggan merely mirrors the setting (value flipped), then I can't see any harm done by disabling the ability to modify the setting in core and moving it to LoginToboggan?
Comment #3
hunmonk CreditAttribution: hunmonk commentedthis is a good start, but needs some corrections/further investigation:
or, alternatively:
i'm wondering if a cleaner approach here would be to simply form_alter the checkbox item into a '#type' => 'item', and override the description. pretty sure that would look good, and since a form item is not an input type, the system settings form wouldn't try to save the value.
Comment #4
sbrattla CreditAttribution: sbrattla commentedHi,
I've created a new patch where a space has been added after slashes, and I've corrected the 'whether' spelling mistake. Furthermore, the link has been corrected according to your explanation about using url() and not l(). Thanks for your comments!
I'd be happy to change the checkbox to an item, but my only worries is that it might lead to confusion when someone will be looking for a setting which all by a sudden has been removed by another module. People rarely read descriptions, so by letting the checkbox remain as disabled might avoid confusions. What do you think?
Comment #5
hunmonk CreditAttribution: hunmonk commentedlooking better. i can get behind your reasoning for making it a disabled checkbox.
in which case, list item 3 from comment #3 above still needs to be addressed, then i'm happy to test/commit.
Comment #6
sbrattla CreditAttribution: sbrattla commentedHi,
I've updated the patch according to comment #5. Sorry for the delay!
Comment #7
hunmonk CreditAttribution: hunmonk commentedcommitted to 7.x-1.x-dev, thanks!