Hi;
I read in Administer -> User management -> User ReadOnly -> Default settings for all fields -> Restrictions mode:
"Note that password-type and date-type fields cannot be disabled; they must be deleted."
A) Can you please explain what would happen if months or days latter, I need to go back and allow users of a certain role to be able again to edit those password-type and date-type fields? say for example the main password in the Account Information section?
B) I don't see that note on the main Account information » Password section; does it apply there? is the password field deleted there?
C) Please explain how can I configure User Read-Only so that I can disable editing of password fields but be able to re enable editing of them if needed in the future, all this in the scope of a particular user role.
Thanks a lot for your help
Comments
Comment #1
deekayen commentedThe choice of words on that page is misleading. What it should probably read is
Deleting, in the context of that configuration page, does not mean to disappear forever. It is completely reversible by changing the configuration from deleted to allowed, or disabling and/or removing the module.
Comment #2
vr_mex commenteddeekayen;
Thanks a lot for prompt response and clarification; right as you said that Note should be changed to reflect correct behaviour of User Read-only module.
1.- What happens in following scenario:
a) password editing is disabled in Account Information section for a specific role.
a) a user registers for the first time to the site,
b) Drupal sends a welcome email and explains account needs admin approval, which is in process...
c) Administrator approves account via normal drupal user management procedure
d) user receives normal drupal generated Account activation email where it states that he will be redirected to enable his password, it says it is a one time link...
e) user clicks link in above email and then he is redirected to the password edit; can he edit password for just that time?, what happens when he arrives to that section? is he locked out?
So in this scenario in which a site needs to have Administrator approval of new user registration, how are passwords generated and issued to the new user? and what happens with the default Account activation email?
What is the correct way of doing this ?
Thanks again for your help ;-)
Comment #3
deekayen commentedI did that on my test site. My test user got an email that said the account was pending approval with a username and random password. The admin got an email to approve the account. As admin, I activated the account, and it sent an email to the test user with the replacement login one-time URL. Instead of clicking the URL that I knew would work, I used the login information from the welcome, you're pending email, which worked, but the password field is hidden. All that boils down to if you're going to approve accounts, but deny password changes, they'll have to stick with the password they're issued at account creation or admins will have to change passwords for them. If I hadn't turned this issue into a task, I would mark that specific functionality "by design".
With regards to the task, I renamed disabled to read-only and deleted to hidden.