|
|
|
This could be implemented by adding two different form fields and removing the one that is not used in definition_after_data() - one for old style change, the other for change with confirmation.
Agreed that people with the ability to edit all profiles don't need this.
For others, I don't think we need to maintain or show anything about the pending change in the main form interface, if we do it like this: When you hit submit: iff the email was changed then you see the message telling you that the email will not be changed to the new value until you read the email at that address and click on the link found there, with a continue link. if the email was not changed then just go straight to the profile page as we do now. Since nothing happens until they press the link in the email there is no need to do anything special for resending etc. Ignore the last file, try number 3 instead!
1/ we must add email duplicate test into user/emailupdate.php just before saving the new one - the timing could work against us there
2/ admin option to turn it off 3/ print_continue("$CFG->wwwroot/user/view.php?id=$user->id", true); -- true does not print the continue button 4/ name of site in email header missing 5/ missing name of user in that email too 6/ I think the key may be shorter - 20 chars? 7/ oh! print_simple_box() is deprecated - use the alternatives instead ;-) Attached a patch with all the fixes Petr suggested
for some reason the patch does not apply for me to current 19x
1/ missing $a->fullname = fullname($user, true); in auth_emailupdatemessage 2/ there should be some info when editing profile that email change is pending the rest seems ok :-) Fixed in 1.9: Also added a "Cancel email change" link and an admin option in Security -> Site policies section
oops, this does not work because useredit_update_user_preference() was not intended for this :-(
working on a fix... had to tweak it a bit, tested, works for me, yay!
thanks everybody :-) there are some logs displayed on the top of the confirmation page (1.9):
SMTP -> get_lines(): $data was "" SMTP -> get_lines(): $str is "220 outbound.icp-qv1-irony-out4.iinet.net.au ESMTP " SMTP -> get_lines(): $data is "220 outbound.icp-qv1-irony-out4.iinet.net.au ESMTP " SMTP -> FROM SERVER: 220 outbound.icp-qv1-irony-out4.iinet.net.au ESMTP ........... Where are you seeing these? I just tested with the latest from CVS and all seems to be well. I tested with both sendmail and SMTP server. I'm curious what might be causing this. Peace - Anthony
Is this what Jerome means by confirmation page?
here is the confirmation after clicking on the link (w/smtp server)
Anthony, it's apparently in lib/phpmailer/class.smtp.php, there is echo "SMTP -> get_lines(): \$data was \"$data\"" ...
I keep going to test this issue and I'll write a bug for the log stuff if needed. tested on 1.9, 1.8 and Head
My tests: When option is turned off: - student can change his email address When option is turned on - admin can change email address - student needs to confirm by email (try accept and cancel) - if email address has been taken by someone else before validation, an error message appears when student click on the email confirmation link Remarks: - In 1.8, the option is located in the "Module Security" folder. In 1.9 and HEAD it's in Site Policies. It would be better to be consistent between version. - If I don't set any SMPT server and turn the option on, a student can change the email address, then he gets an error (not very friendly on a blank page), and the profil page says that Moodle is waiting for a confirmation. However no email was sent. The student has to cancel the change. (behaviour tested on 1.9, 1.8 and 2.0) - my previous comment (08/Jul/08 11:16 AM) concerns only 1.9. These SMTP logs appear on the page displayed just after clicking on Update on the profil page. I'll write a new issue for that. Otherwise all works fine :) If the remarks are not going to be fixed, you can close the issue. Thanks. about SMTP logs, it's not a bug, I had SMTP debug turned on in administration. Oops...
there is a die("could not send email!"); in user/edit.php, that should help diagnose smtp sending problems for now
thanks for the review, reclosing Ok 1.8, option setting is now in Sites Policies. All good.
I made a little fix to make this work even when that user's email is currently disabled.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
* email change is pending (some info in edit form)
* email will not be changed immediately (info in form)
Also there should be an option to cancel the change.
Users which are allowed to edit profiles (such as admins) should not be asked for confirmation.
Maybe a resend option.
Looking forward to patch, this will be a great improvement ;-)