After creating a new account, if the user tries to log in before the admin has approved the account, they are currently given an error of "The user account username has been blocked."
This is a bit misleading, and this simple patch to user.module changes that message to "The user account username is currently inactive."
It also changes the label on the user form radiobutton from "Blocked" to "Inactive", and similarly when viewing the admin user list.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | user.module.diff.txt | 930 bytes | drumm |
| #9 | patch_3.diff.txt | 1.57 KB | stmind |
| patch_3.diff | 1.56 KB | stmind |
Comments
Comment #1
Steven commentedIsn't blocking users exactly what that feature is for?
Please don't submit non-trivial patches as RTBC by the way.
Comment #2
stmind commentedThanks. Yeah, to us it's perhaps minor semantics to us, but to a user there's a big difference between "blocked" and "inactive". More than once a new user trying to log in has asked why I blocked them, when in fact I had simply not approved them yet. Blocked implies something different than Inactive.
Sorry about the status flag. The changes are simply three strings.
Comment #3
stmind commentedTested with 4.7.0 release.
Comment #4
dwwi'd almost set this to "won't fix" and point people to extended user status change notifications, especially once i implement and commit #61498. users should never see a temporary password until the admin has approved the account.
once that's true, none of this effort is needed at all.
my $0.02,
-derek
Comment #5
pwolanin commentedAs best I can tell, this is a contributed module, right? Are you (or can we) lobby to get these changes into the core user module for the next release?
Comment #6
dwwyes, it's contrib. i'll try to lobby to get this functionality into core, but i'm not sure if that's going to happen. just because something's contrib doesn't mean it can't/shouldn't be used. the event module has lived outside of core for ages, and is one of the most important modules in drupal IMHO. ;)
Comment #7
drummThe inactive message isn't much better. Having just registered on a hypothetical site, I would not consider myself inactive.
I think the real problem is trying to use two states for unapproved, blocked, and active.
Comment #8
dwwi maintain the real problem is revealing a means for users to attempt to login before their account has been approved. drupal should never do this. that's what my contrib module will provide in the near term (once it supports sending 1-time login links whenever an account is set to active). i'd love to see the functionality folded back into core, but i don't know how feasible that is. i don't think it's worth the complication of a whole new state for "pending approval", we can continue to use "blocked" for that, so long as the end user is never given the false impression they're able to login until the account has been unblocked.
Comment #9
stmind commentedI agree, it would be better to simply not offer the login info until a user is approved.
However, there woudl still be a number of ways that a user could potentially try to log in while the account is inactive, in which case the error message still applies.
In response to Drumm, I've altered the string to:
The account for %name is currently not activated.I think that further clarifies it for the user. See attached updated patch.
Comment #10
stmind commentedComment #11
drummI don't think wre should remove the word blocked.
Attached is my proposed change (with a third state being added or different emailing happening later).
Comment #12
dwwi agree we don't want to remove "blocked" from the drupal volcabulary. drumm's patch seems good to me. i still think hiding the password until the account is active is the real solution to this problem, but this is a reasonable temporary measure until we can fix that underlying issue.
Comment #13
dries commentedI support Neil's patch. I'll commit it if no one has strong objections. We can still refine this later on.
Comment #14
dries commentedCommitted to CVS HEAD and DRUPAL-4-7. Thanks.
Comment #15
(not verified) commented