Closed (won't fix)
Project:
Drupal core
Version:
4.7.0-beta4
Component:
user system
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
6 Feb 2004 at 18:40 UTC
Updated:
15 Mar 2006 at 18:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
stelman commentedIs there a way to do this yet in 4.5.0?
Comment #2
dschuetz commentedI've wanted this functionality for a while now, and have whipped together a simple patch that I'd like to submit for comments. It's not against HEAD, but is a patch to 4.5.1, so I'm not sure if I'm supposed to submit it as an actual patch request. The patch is attached (let me know if I should'a generated it differently).
Usage details:
The patch adds a new email template called "activated_subject" and "activated_body". I moved the email information providing a new password and describing how to edit your account from the "pending approval" email template to the "activated" template, and added a notation that a password would be sent as soon as the account has been activated.
To send this new email, a checkbox was added to the user edit form, just under the "Status" radio button. When an administrator checks this box, *and* the Status is set to "Active," then the "activated" email will get sent to the new user when the form is saved.
I did not include a template for blocking a user, as it's likely to be rarely used, and in any event, each particular instance of a block is probably going to require its own custom email describing why the account has been blocked. That said, there might be room for expansion here with a set of "standard" account block messages, like for when an account has been too idle, or been used for SPAM, or so forth.
Technical Details:
The bulk of the changes are in user_save(). Early on, we check to see if the "notify_email" field contains a 1 (meaning the checkbox is checked), and that the "status" field is also equal to 1 (meaining "Active"). If so, then we continue with my patch. First, we check whether the 'pass' variable is null. If it is, then no password was set in the form, and so we create a brand new random password for the user. If it's not null, then the admin manually changed the password, and we simply let that get used instead. Then, we create all the appropriate variables to be substituted in the email template, and send the email. (this section of code basically copied from elsewhere in the module). ** NOTE - As I look over the code this morning, it seems that perhaps this whole section should have been moved outside the "if ($account->uid)" check, so that it will work for both activating existing users and for when an administrator creates a brand-new user. That would answer several other requests I've seen, I believe. ** When done with all this, the "notify_email" variable is cleared from the user data array, so that the SQL calls don't try to update a non-existant field. (I'm a little fuzzy on that part).
In user_edit_form(), I add the checkbox right after the Status radio buttons and before the Roles checkboxes. It's labelled "Notify User," the variable is "notify_email," the default status is unchecked, the checked value is 1, and the help text is "Send the user an email with a new password when activating the account."
In _user_mail_text(), I modified the template for "approval_body", and created templates for "activated_subject" and "activated_body." Changes are as described above.
Finally, in user_configure_settings(), I added textarea and textfield edit blocks for the "activated_subject" and "activated_body" templates.
Request:
I've seen a few discussions where people have asked for a feature similar to this. Though this doesn't address all possible capabilities, I think it satisfies the basic need, and leaves the door open for future expansion with other templates (as described above). As this is my first real submission of a change, I'm not completely certain of the process to follow here. I'd like to hear comments from others, especially on the design and approach of the change. If it's good, and if my note above makes sense and can be changed and tested (about placement of the main patch with regards to brand-new users versus activation of existing users), then how do we get the status changed to a formal patch request, and get that review process rolling?
At any rate, I hope this helps!
david.
[Related discussions:]
http://drupal.org/node/1828
http://drupal.org/node/1817
http://drupal.org/node/15128
http://drupal.org/node/5671
Comment #3
killes@www.drop.org commentedNote that new features will only be added to the cvs version. Personally, I think that this is quite a large patch for a simple feature. Couldn't you re-use some more existing code (especially for sending the mail)?
It would also be possible to create a custom module for this. It would need to implement hook_user('update') and look for changes in $user->status.
Comment #4
dschuetz commentedNote that new features will only be added to the cvs version.
So all work has to be done against HEAD? I guess I'll have to set up a test site, then...
Personally, I think that this is quite a large patch for a simple feature. Couldn't you re-use some more existing code (especially for sending the mail)?
I don't think it's that large, really: 1 line to add the checkbox, 2 lines to edit the template subject/body, 4 lines (plus one changed line) to define the template, and 15 logical lines (broken up for clarity) to do the meat of the patch. It'd be nice to reuse some of that email generation code, but it's already duplicated a couple of other times in the module and I'm not sure it'd be too easy (or worth the trouble) to combine it all into a new function.
It would also be possible to create a custom module for this. It would need to implement hook_user('update') and look for changes in $user->status.
I dunno, somehow that seems like it'd be overkill for just adding a single checkbox to implement what seems like a frequently requested feature.... (and quite a bit larger, at that.)
Comment #5
(not verified) commentedI would agree with dschuetz, that this should be part of the user.module. This seems like a logical extension of the current module. I was suprised this didn't exist in the original functionality. If you are going to have a visitor approval process, it is essential that all but the decision to approve be automated. Otherwise this could get really time consuming for a site admin, quick.
Comment #6
koorneef commentedAny progress on this ?
I'm also very interested in this feature !
Let me know if I can help: test patches or anything else.
Comment #7
ferid commentedI'm also looking for this feature!!!
Can anyone tell me if it will work for 4.6?
Comment #8
TimCottee commentedI too would be extremely interested in this, have deployed a drupal based site and have the same issue. I need to ensure that members are approved based on certain criteria but have had comments back that the users do not know when they have been approved. Would be more than happy to test any patch, not yet in a position to start trying to write one myself though.
Comment #9
stelman commentedMe again from Oct 2004.... just posting again to show there's still interest. When I have time, I'll see if the patch above can be made to work in 4.6.2
Comment #10
bluecobalt commentedAny word for 4.6?
Comment #11
robertdouglass commentedThe current discussions are for 4.7 usability. This definitely fits the bill. If someone can re-roll this against HEAD and bring it to people's attention, we could get this in for 4.7 It is a much wanted improvement.
Comment #12
bernardf commentedHi there.
I'm new to drupal and I badly need this feature. It seems that for years people is asking for it and it does not show up.
I'm running 4.7-beta4, I filled the parameter/user form with a 'confirmation of registration email' but see no way to have the user receive such an email. Did I miss something?
Thanks.
Bernard
Comment #13
dwwi know this won't be applied to user.module for 4.6, since that's now frozen. however, those of us still using 4.6 sites can manually apply this patch and get the desired functionality. i basically just took the original patch from dschuetz, and updated it to work with 4.6 (a few bug fixes and minor changes to get it to apply cleanly and work properly). this patch applies cleanly against user.module revision 1.454.2.21, the current end of the DRUPAL-4-6 branch.
time permitting, i'll work on an equivalent patch against 4.7, but i figured i should share my efforts for anyone else (e.g. bluecobalt or stelman) who wants this in 4.6. i have the sinking feeling 4.7 is also now frozen, so this might not make it into the core for 4.7 either, even if i did the work. alas.
anyway, 4.6 users, here you go...
-derek
Comment #14
dww(whoops, accidentally changed the title... thought i was entering a subject for the comment)
for the patch-challenged, here's a complete copy of a 4.6 user.module with the above patch already applied (and a commented added at the top so you can see it's not a real version of revision 1.454.2.21).
to use, just save a copy of your existing user.module file, then download this and rename it to user.module in your modules directory.
enjoy,
-derek
Comment #15
shouchen commentedDerek,
I saw your e-mail on the development list. Even if it can't get in for 4.7, I'm sure lots of us would appreciate being able to add this behavior via a patch. A 4.7 patch would be greatly appreciated.
-Steve
Comment #16
deekayen commentedI want this for 4.7, too.
Comment #17
suehami commentedI'm an extreme newbie to drupal and I'd like to use this patch within my site. I found this thread by searching the problem so forgive me if I'm posting to the wrong place. I have a very basic question:
Do i simply replace the current user.module file with this user.module-4_6_notify_activation file and rename the file to user.module?
Incidentally having followed varius threads from around as early as 2004 I'm surprised that this functionality isn't part and parcel of Drupal
Thanks for any assistance
Sue
Comment #18
deekayen commentedhttp://drupal.org/node/38825