Split “blocked” status into “pending” and “locked-out”

Problem/Motivation

(Why the issue was filed, steps to reproduce the problem, etc.)

There is currently a duplication of terminology in Drupal which, in and of itself isn't confusing, however when searching for modules or help, the two become severely blurred. The term I am referring to is "Block". On one hand, we have a "Block" referring to a visual entity, as in, "He added content to the block, and placed it in the footer." However this term is also used in reference to a user, as in, "The user caused problems, and so he was blocked from the site." Spoken of in context, either instance is clear, however, just as an example, as I filled out the form for this issue, I looked at the list for "Component". There was the "User System", but there was also the "Block Module". I had to stop and think seriously about which "block" this was referring to.

Proposed resolution

(Description of the proposed solution, the rationale behind it, and workarounds for people who cannot use the patch.)

As "Blocks" are well established as a visual entity within Drupal, and I believe that attempting to change this term would be, at best, extremely difficult, I believe that the best plan of action would be to modify the User related term. There are a variety. Myself, I think the term "Lock-out" or "Locked-Out" would work well in substitution. "The user was blocked from the site"/"The user was locked-out of the site." I think that this would be an easy substitution in terminology which could easily be put into place in any upcoming Drupal update.

Going hand-in-hand with this "user issue", is a User Management issue. Currently, whether a user is brand new, and hasn't yet been approved by an Administrator, or the user is a troublemaker who has had their privileges suspended, they are shown as "Blocked". This can be difficult for the Administrator if they have a number of user accounts falling under this category. For example, I have several sites where spammers are creating bogus accounts with user names like "lklnspdiw1966". After looking into this matter, I choose not to cancel these obviously fake accounts, so that the e-mail address cannot be reused. The issue however becomes that I have large numbers of "fake" accounts which I leave as "blocked". However it quickly becomes easy for a legitimate new user to become mixed in with these fakes, and be overlooked. The solution that I would suggest is implementing an additional role status, "Pending", which a NEW user would be placed into. Having the TWO roles would allow me to look over my user list, as i do, and any "fake" accounts could be selected as a group and switched to "Locked-Out" status, while any legitimate users would be processed/approved. Ideally there would also be a switch in the "People" list, where in one position it would show ALL uses, while in the other, it would hide the "locked-out" users.

Yes, I realize that I can already create an additional role myself, however when I attempted to create a "Locked-Out" role, it wants to still grant some basic privileges, similar to the Anonymous user. My desire is to have a second category with NO PRIVILEGES, like the current "Blocked" status.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

Change the current "Blocked" user status in CORE to "Pending", and add an additional user status role "Locked-Out", which has NO privileges, also add a switch on the Administration User Screen, which toggles the visibility of the "Locked-Out" class on and off.

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate.)

These changes should have no impact on any existing modules/profiles/etc.

Data model changes

(Database or configuration data changes that would make stored data on an existing site incompatible with the site's updated codebase, including changes to hook_schema(), configuration schema or keys, or the expected format of stored data, etc.)

These changes should have no impact on existing sites.