Add option for additional user statuses

[stpaultim]

Description of the need

Core comes with only two possible user statuses.

1. Active
2. Blocked

The question was rasied in Zulip recently whether or not this is too limiting. There may be situations in which a user is no longer active, but for which "blocked" is too strong a label. In the Drupal issue queue, someone asked about the following examples.

• Unverified: user has not verified email;
• Inactive: user has not logged in, but is verified;
• Active: email verified and user logged in at least once;
• Suspended: a temporary number of days being blocked from access.
• Banned: mod or admin permanently blocked user.
• Blocked: an automated system blocked user.

https://www.drupal.org/project/drupal/issues/3225766

Proposed solution

Either add an additional status or make it easier for site architects to create customizable statuses. If we added a status, I think it may be difficult to decide which one. For me the most obvious would be something like "inactive". Something in between "Active" and "Blocked."

The ability to add custom statuses would be more flexible and address a greater range of use cases, but obviously adds complexity.

Alternatives that have been considered

I suspect that many situations in which additional statuses might be useful are currently addressed through the use of roles. Maybe that is good enough?

Is there a Drupal or Backdrop contributed module that accomplishes this?
...if so, then please provide a link.

In the Drupal issue queue, this module is mentioned as a solution. But, I have honestly not thought about it long enough to know if how this modules solves the problem.

https://www.drupal.org/project/state_machine

Additional information

I'm opening this issue without any urgency attached to the issue. I just think it's an interesting question and one worth discussing.

Draft of feature description for Press Release (1 paragraph at most)

Backdrop now includes the ability for user accounts with more than just two possible statuses, blocked or active. We now have the ability for finer grained states or statuses.

[NormPlum]

I think adding one or more additional statuses won't solve the problem, as someone will surely come along with a different need that's not catered for.

So I think the better option is to allow for site admins to create/define their own statuses.

Having said that, I like @stpaultim's idea about using roles for this. We'd just need to add additional permissions/functionality to allow for things like:

• Preventing login if the user trying to login has a role that doesn't allow this (think 'inactive' or 'blocked' roles)
• (any other functionality that statuses should provide)

[bugfolder]

I suspect that many situations in which additional statuses might be useful are currently addressed through the use of roles. Maybe that is good enough?

It seems like Roles are basically an admin/contrib-definable way of extending the concept of status.

As for adding new values to the status field, I suspect there is a lot of code out there that checks $account->status directly that might get confused by other values, e.g., if ($account->status == 1) being different from if ($account->status).

[avpaderno]

With a new role, there would not be any problem with correctly handling the status value. (That should not be an issue, if the User class had ::isBlocked() and ::isActive()).
With a new role, people with the permission to administer user accounts should remember they need to assign that role and remove other roles. When the account would need to be unblocked, they should remember which roles that account had.

[avpaderno]

Looking at the statuses listed in the issue summary, I wonder if those are necessary to show a specific label on account profiles (or change in some way how an account profile is rendered), or to change the permissions an account has.
In the first case, the existing fields the User entity has should be sufficient; for the accounts without a verified email, a new field could be used. In the second case, it is a matter of giving to the accounts one or more roles.

Currently the status field just means that an account can be used to log in (when its value is 1) or cannot be used to log in (when its value is 0). Would the new statuses mean the account can be used to log in, or that it cannot be used to log in?

[olafgrabienski]

I'm skeptical about adding a new status (for the same reasons mentioned by others in this thread). I think however, some problems come from the label "blocked" for a status value of 0. The term carries implications that may sometimes invite treating accounts with this status negatively, i.e. blocking functionality or content which is easily available for anonymous visitors. For this reason, I'd prefer to switch to a more neutral term for status 0, i.e. "inactive" instead of adding more statuses.

[bugfolder]

With a new role, people with the permission to administer user accounts should remember they need to assign that role and remove other roles. When the account would need to be unblocked, they should remember which roles that account had.

With Rules module, one could automate that process by setting up a rule reacting on "Before saving a user account" and adding/removing roles as desired.

The term ["blocked"] carries implications that may sometimes invite treating accounts with this status negatively, i.e. blocking functionality or content which is easily available for anonymous visitors. For this reason, I'd prefer to switch to a more neutral term for status 0, i.e. "inactive" instead of adding more statuses.

But setting atatus to 0 actually does block functionality; it not only blocks logging in, but it also blocks the ability to create a new account with the person's email address (the email address of the blocked account).

And I would think of the term "inactive" as being something different, e.g., describing an account that hasn't logged in or accessed the site in a while, but is perfectly welcome to do so.