META-roles, user registration handling and SPAM registration

Explanation looks good. Haven't reviewed the code yet. Two quick comments:

1. Let's not introduce an adminsitrator role. The $user->uid is fine at the moment.

2. When I read the list of roles, the difference between pending and unconfirmed wasn't obvious. It wasn't until I read the explanation that the difference made sense. I'd like this to be obvious at first sight (i.e. be made more intuitive).

What's the status of this issue? Will this be committed for 4.8? These extensions to user roles are badly needed.

I am also confirming that we need a administrator role. Since we're working in a team, All of my Drupal sites are developed and maintained by more than one developer. Additionally we have a separate person for site administration of each Drupal site.

Some thoughts:

• The description of this issue does not clearly state whether the corresponding actions for changing a user's role from 'Unconfirmed' to 'Pending Approval' or 'Authenticated' will be included in this patch, too?
• Will administrators be able to decide whether users are automatically approved?
• Will those meta user roles be separated in the user/edit form? One of these meta roles has to be set, while (an)other user role(s) may be additionally assigned.
• I would propose to add the tabs 'Authenticated', 'Unconfirmed' and 'Pending Approval' to admin/user for filtering actual site users for administrators.

This would be very useful in the Drupal. I'm moving it out of x.y.z issue queue to the 6.x-dev queue. It also sounds more like feature request than a bug.

[subscribing]... I might try updating the patch on this later on, but I'm not making any promises.

I think the simple matter of providing an administer role by default should be a separate issue, and could be done in D6.

The administrator role is a role I think the majority of serious users create themselves. Providing it in Drupal core (and nothing special about it, just a pre-made user-created role, if that makes sense) would be for the explicit purpose of letting modules set intelligent default permissions for this role

This will greatly increase Drupal's usability and ease of use. The enable a module and set permissions two-step shouldn't be necessary.

If anyone agrees that a simple administration role -- no new functionality, just so it's there for use when modules provide default permissions, please un-dupe http://drupal.org/node/182023 and comment there.

I agree with the additional role detailing, it sounds like the right way forward.

Joel

subscribe - referral from #171117: Regression: users without administer users permission can not access user profiles of users that never logged in , which points out the continued need for this patch. In that issue, we're seeing that the lack of this has made a mess of the user data in a hack effort to distinguish the unconfirmed users from everybody else.

subscribe here too. This looks like the way to fix it.

Yes, this looks like a good plan. I'm not sure it covers Michelle's way of running her sites though.

IAC, the numbers assigned to the constants should not be consecutive. The administrator meta role went from 4 to 6 in two days, because new meta roles crowded in. Having these numbers change on a live site has the potential to create all sorts of problems. Especially the admin (if it becomes part of this) ought to be far away, like at 100.

@salvis: The roles are defined. Why would their number changing be an issue? Just make sure that you always use the constant, which should always be the case.

@Susurrus: From the OP:

The status code must be set so that we can control access by checking if $user->status >= 3; do stuff.

If you want to use operators like >=, you need to keep the sequence in a logical order.

OTOH, you can use all the names you want, but in the database there'll be numbers. This means you have to define your constants in such a way that you never need to change them.

Also, if push comes to shove, you'll be glad if you can look at a database table and figure out what it means.

What about removing the Meta-Role ideology all together and use roles instead? Add a "Blocked user" role and remove {user}.status. Then, we can expose certain permissions to blocked users in admin/user/access if we want to.

Why not use a binary sequence like 2, 4, 8, 16

Bit fields or boolean flags are what you're referring to. $user->roles is kind of implemented the same method as what you're discussing here:

if (in_array('administrator', array_values($user->roles))) {

If we got rid of the meta-roles ideology all together, you could expose parts of Drupal to users that are blocked users (like allow them to see their user profile page, but nothing else). This means, remove $user->status and replace it with a "Blocked" role. Thoughts?

I quite like the idea of a blocked role as opposed to the status flag.

I think what that means is a role beneath authenticated user. On forum sites it's quite common to temp-ban users for a day or few - you don't necessarily want to stop them using tracker/uid or private messages but need to stop people posting on the forums. In the Drupal handbook, if I understand it, one possible issue with giving edit rights to authenticated users would be there's no way to take it away from one specific user without banning them completely - so it might help for that kind of situation too.

I can think of two ways of doing it - a role which is sub-authenticated user, and which authenticated user inherits from - and could be used for blocked users and those who haven't completed accounts yet. Users would have to be moved into authenticated by default, with actions/triggers set up for the registration/blocking cases or something.

The other way would be a blocked role that doesn't inherit permissions from any other role - I can't think of any way the UI could work for this.

So a role.reverse column would be set to apply a reverse logic to the permissions?

As in #23, I can't think of anything worse from a UI perspective (in fact I can't imagine what a UI would look like for it apart from horrible glimpses of checkboxes and weird backgrounds). It would solve some problems doing it like this, but I think it'd create much more.

I'm leaning towards two extra roles and slightly changing the behaviour of authenticated:

Anonymous - same as now

Sub-Authenticated - defaults to the same permissions as anonymous - all users get this role and this is where permissions are inherited from. We'd probably lock this one so users can't be taken out of it.

Authenticated -all authenticated users get this - but maybe from an action, and could be demoted from it. It's this one that replaces the meta roles. This'd allow the criteria for getting this role to be varied (require e-mail verification, fill out extra profile fields etc.), and it'd allow for extra intermediate roles to be added since there wouldn't be anything all that special about authenticated user any more apart from some default settings and the permissions that it currently has in core.

Admin - has all permissions added by default, replaces user/1 special casing, user/1 is put into this role by the installer.

Probably big holes in those ideas but fwiw.

Would it be possible to combine the different ideas here and do something like the following?

• Keep @beginner's original idea of expanding the $user->status codes, but don't associate them directly with any roles/meta-roles. Even if you don't want to give a user any new permissions immediately after they have completed a verification step (e.g., confirming their email address), it still can be useful to keep track of this information and know they have done it -- that's the basis of a solution for the profile spam problem, right?
• Instead, associate $user->status codes with role changes only through a "trigger-action" kind of system, as @catch suggested.

The administrative UI for managing the user registration process would then look something like the following (basically just an ordered list of status changes, each of which can optionally trigger a role change):

1. "account is created" => user gets put in role A
2. "administrator approves account" => user gets put in role B
3. "user confirms email address" => user gets put in role C

When registering for the site, the user would be presented with the above steps in order, and each time they complete a step their $user->status code would change. (In the long run, it might actually be possible to let them do these steps out of order too, or let the site admin change the order and add new steps via contrib modules, etc, but maybe that should be saved for later because it would get complicated.)

In keeping with current Drupal behavior, any of these steps could be disabled (a.k.a. made "not required"), except the first one, of course. Furthermore, the administrator would be allowed to change the role assigned to any step, or not have a role assigned to that step at all. If the user has gone through some registration steps but has not yet been assigned any roles, then there could be two possibilities:

• the user is not allowed to log in [this would be the default]
• the user is allowed to log in but gets the same permissions as anonymous

I think doing it this way might allow the assigned roles to be treated exactly like normal Drupal roles; they could be created by the site admin if desired and would not have to be hardcoded in. At the end of the registration process, a user would simply have the combined permissions of all the roles they picked up along the way. Does that seem like it would work?

I'm not sure what to do about a single hardcoded role for "authenticated" users, though:

• One possibility is @catch's idea in #25, where a role would be hardcoded into the first "account is created" step above, and all logged-in users would always have that.
• Another possibility is to hardcode a role at the end, which all users would get once they have finished the registration process. I guess that is closest to the current Drupal behavior.
• Finally, the most radical idea would be to hardcode nothing. So a default Drupal installation would look like this:
  1. "account is created" => [no role is assigned]
  2. "user confirms email address" => user gets put in "authenticated users" role

  But the "authenticated users" role that ships with Drupal wouldn't be special, and it could be unassigned, deleted, etc.

Not sure what the right option is here; they all seem to have strengths and weaknesses. The last one is probably the most intriguing, but also the most tricky.

Also not sure what to do with admin-created accounts... they should definitely get the "account is created" and "administrator approves account" $user->status codes (and any roles associated with them), but I'm not sure about anything else. It doesn't feel right to mark their email address as having been validated when it has not.

Anyway, just some (rather long) thoughts. I suspect there are some big holes in these too, but this is a tough problem ;)

As for blocked users: I think there is definitely a valid use case for something similar to what Drupal already does, where you have a single flag that blocks the user but doesn't change anything else. In the current context this would mean that their status and roles stay the same, but they aren't allowed to log in.

However, on top of that, the idea of a "blocked user" role (really more like a "demoted user") makes sense, and I think it would be possible to implement; you would just have to unassign them from any roles they picked up along the way (during the registration process) and reassign them to a new, more limited one, right? Demoting a user to a lower status (e.g., marking their email address as unvalidated) could also work here, probably. I'm not sure if that is something that belongs in core or contrib, though.

One more thought: I personally think "authenticated users" is already a bit of a confusing role name, but it would have the potential to be even more misleading and inaccurate if some of the ideas here were to be implemented. I'm not so sure if "sub-authenticated" or "pre-authenticated" are good either (?).

How about something like "site members"??? Not sure it's great, but it explains more who the users are than how they got there, and I think that's arguably better. (Then maybe "anonymous users" could become "nonmembers" too, although I'm less sure about that idea.)

Ick, let's not dumb down the users. Administrators should already know what authenticated and anonymous users are.

OK, I think I agree with you about the anonymous users, at least. The concept of "anonymous user" does have a clear technical meaning which we shouldn't try to obscure with friendlier terminology... so I retract my idea of changing that to "nonmembers" ;)

But for "authenticated users", I'm not sure. It's technically an accurate name now, but with many of the ideas that have been suggested above, that would change. Right now "authenticated users" is its own role because Drupal is designed so that all logged-in (a.k.a. "authenticated") users are equal at some base level. But I think the point of most of the above discussion is that the distinction should not be such a binary one. If your site wants to let users log in and play around with their personal settings after they have created an account, but not let them do anything more special until they have actually clicked on the validation link in their email, then the concept of an "authenticated user" role may legitimately cause confusion for you.

Here's a more concrete example: If we went with my suggestion, then on a fresh Drupal installation you would go to the permission page and have two roles to assign permissions to: "anonymous user" and "site member". If the concept of "site member" is not applicable to you, you could delete this role or rename it, etc, since it wouldn't be hardcoded. But otherwise, you would only have one main question to answer while you're on that page: "What permissions do I want my site members to have?"

Then you would head over to admin/user/settings, and the question you would answer there is: "What do users have to do in order to become site members?" The default settings would look like this:

1. "account is created" => [no role is assigned]
2. "user confirms email address" => user gets put in "site members" role

If you then decide that you'd also like to approve everyone by hand before they can become "site members", you just change it to this:

1. "account is created" => [no role is assigned]
2. "administrator approves account" => [no role is assigned]
3. "user confirms email address" => user gets put in "site members" role

And if you later decide you'd like people to have access to a limited set of permissions before being approved, you could just create a new role and change the settings to this:

1. "account is created" => user gets put in "probationary members" role
2. "administrator approves account" => [no role is assigned]
3. "user confirms email address" => user gets put in "site members" role

From my point of view, this wouldn't be dumbing down Drupal at all, but rather making the terminology more accurate and the admin interface more flexible and intuitive... what do you think?

Couldn't this be handled in a module; such as Advanced User or even one called User Actions?

You may be right. Actually, I think the LoginToboggan module does a very limited version of this (with "pre-authenticated" users) now, although I've never looked at how it implements it (?). I just thought that @catch's idea of assigning roles via a trigger-action-type system was cool enough and general enough that maybe it belonged in core, but I'm not sure. (If you do leave this to contrib modules, then the question doesn't necessarily become any simpler, though; at that point core definitely need to hardcode an "authenticated users"-like role somewhere in the process, and exactly when to do so still seems like it's unsolved, based on the above discussion?)

A user.module permission could be "access site" or maybe "access login" to stop the user from logging into the system if the user is a member of a role that doesn't have this permission set..... The "access site" permission would easily implement the "blocked user" role.

I guess this might work. But I don't think it's ideal for the following case: Suppose you have an important user who has been assigned a bunch of different roles on your site. You suspect their account has been hacked into so you decide to block it temporarily while you sort things out. Once you're satisfied everything is OK, you want to restore the account exactly back to the way it was. A simple boolean "blocked" flag as Drupal does now is perfect for this... but if you implement blocked users as a role only, then it's much more of a pain, and you need to remember exactly which roles you had them in and assign them back to these roles by hand, etc... Does that make sense?

But we need to know if user.visible is TRUE for the whosit blocks and the user profile pages; we may want to see the user but not allow the login. We may want to not see the user but allow the login. We may want all but one user visible. We may have a user invisible and not able to login.

This seems reasonable, but can't the value of "user.visible" just be a setting that depends on the others? As you say, different sites might have different policies for when they want the users to be visible, but it seems to me like these policies would all depend on $user->status (e.g., whether or not the user has clicked on an email validation link) or "$user->blocked" (e.g., whether or not the user has been blocked by the site admin), etc. So would "user.visible" work as a setting, rather than something that needs to be stored in the database directly per-user? I'm not sure...

I'd like to bring up a related issue.

There is a problem with "authenticated user" functioning as a "role" because it doesn't behave like other rules. Whenever "authenticated user" is selected on a list (e.g. permissions, block visibility, any module that applies functionality by role) it is a big usability issue that authenticated user behaves differently. Selecting "authenticated user" in such a situation applies to all the other roles except anonymous user.

This is a problem when an admin wants to apply some settings to authenticated users who have no other role, but not apply those settings to authenticated users with other roles. This is only possible in situations, such as block visibility, where there is the possibility to create the desired result with custom php. This is not good for non-programmer site admins.

This situation also encourages module developers to create functionality that is not consistent with Drupal's "opt-in" approach toward role settings (e.g. with permissions you click on roles to get privileges, you don't click on boxes to restrict privileges). One example is the Google Analytics module. Prior to version 1.4 you clicked on roles to exclude those pages from receiving the Google Analytics tracking code. That solved the problem of targeting authenticated users who were not assigned any other role. You just check all boxes except anonymous user and authenticated user. But now that UI was at odds with Drupal's general approach on this matter, and the GA maintainers switched the logic beginning with version 1.4. And now they are stuck with the problem I'm describing here. (Read abut this at: http://drupal.org/node/258981)

Relating this back to the issues at hand here in this thread, I really like the idea of meta-roles related to user status. We already have two meta roles, anonymous users and authenticated users. It just beefs that up. It also highlights the fact that these aren't real roles at all.

Durpal would need to require default roles be set up for anonymous and authenticated users. Site admins would be required to create those two roles at set-up time.

The meta-roles related to user status would come in handy in various ways programatically. But the admin interface for most, if not all, situations regarding visibility of functionality could be universally "opt-in".

I was thinking about this a little more, and maybe this whole issue is too broad to deal with in a single patch....

As @earnie pointed out, a lot of the role-related stuff could be dealt with in contrib modules. Regardless of whether that's a good idea, it definitely seems to argue for holding off on the "meta-roles" vs "roles" vs "trigger/action" stuff for now and saving that for a possible followup patch.

So how about the following plan for starters?

• Add a new element to each user, call it $user->validation, to keep track of the validation steps that user has gone through. Probably implement this an array of flags or via bit fields, as discussed in #21 and #22 above, perhaps with just two possible values for now: "email address verified" and "account approved by administrator"?
• Add a good API for finding out if a user has passed a certain validation step, editing the steps they have passed, etc.
• Add a hook so modules can respond to the fact that a user has passed a validation step.

Let's leave $user->status as it is now (binary flag for whether the user is blocked), since that's kind of a different beast....

And that's all (for now); the rest could be saved for a followup patch.

Comments?

I like Catch's approach in comment 25. When he writes:

authenticated users get this [role] - but maybe from an action, and could be demoted from it... there wouldn't be anything all that special about authenticated user any more apart from some default settings and the permissions that it currently has in core

Catch's approach here seems to be to try to get the role system to handle both status and role. I think it would be cleaner to separate the two.

Each status could trigger assignment to a default role. But once that assignment is made, there is no further intrinsic linking between the status and the role. Changes in status can also trigger unassignment of roles. Permissions and visibility settings, however, would be purely based on roles, not status. That's what solves the problem of a status trumping the role system (the case where checking "authenticated user" as a role forces inclusion of ALL authenticated users, even those of a particular role that the admin wants to exclude).

I think the talk of the role.reverse column is the wrong way at trying to solve the the same problem I'm concerned about.

Catch's point about the reversibility of a role assignment that is initially triggered by a status, is absolutely key.

That's it for now.

Shai

OK I think I can agree that there's two issues here:

1. Having a record of the various statuses of users - $has_account $has_validated_email $has_logged_in - we ought to make this extensible somehow so you can have things like $has_posted_content as well.

2. Using these statuses to define which roles users get put into programmatically instead of hard coding authenticated user.

However, I think removing the hard-coding of authenticated user provides a very good implementation of the API in 1 and it might be hard to split them into two issues. fyi I mentioned actions/triggers since it's already got a track record for changing states of things in workflow, and because it's an existing API that's already in core.

As to whether users are visible or not (the original prompt for bumping this issue) - why not have core decide one or composite status which it uses to decide ($has_validated_email && $has_logged_in) - and again set this up so contrib can intervene. I think this needs to be removed entirely from the logic which determines what users with those various statuses can do themselves (i.e. the roles system).

edit: cross-posted with Shai, but seems like we're looking at this in a similar way (at least as it stands now)

I think we may be risking things by tying too much work flow and state logic into core. I'd like to simplify. Currently we have one bit that indicates blocked or not. An access timestamp is being over-ridden to get an additional bit of information, that of profile visibility. Separating that one additional bit, say user->visible would solve many of the issues that we're trying to solve although it deviates from the issue title. user->visible designates whether or not a profile can be retrieved for the person AND whether they show up in any member listings. It's a well defined flag with a well defined purpose.

Core logic would set it automatically on first login (!user-access). In any event it's available in the profile for over-ride.

Site admins need to be able to see everybody, regardless of visibility setting - else they wouldn't be able to change it.

Perhaps one more change to make it all work smoothly is that for exists and !visible and !admin, show a polite message that the profile cannot be viewed rather than the harsh 404.

If you think this needs another issue, let me know and I'll split it off. I'm going after the core problems and leaving the abstraction of roles for another day.

Thinking about the $user->visible stuff here definitely makes sense to me.

I don't think $has_validated_email should be used (as suggested in #38) unless we provide a configuration option to turn it off... sites don't always require users to validate their email address, so this would be bad because all users on those sites would then be invisible.

I'm also not sure $has_logged_in by itself is good either (as suggested in #39)... what do you do with admin-created accounts that haven't logged in yet? Don't you run into the same sorts of problems as in #171117: Regression: users without administer users permission can not access user profiles of users that never logged in ? Maybe we can make it a setting: Leave it up to the site owner to decide whether or not users need to have logged in in order to be visible. Would that work?

As for the main track of this issue, it seems like a few of us are in agreement about how to proceed. I would just say let's try to see if it can be done in two medium-sized patches rather than one gigantic one, although if it winds up being too tangled together, then do it all at once. I'm definitely in favor of getting rid of the hardcoded "authenticated user" role as a great use of the API and an immediate next step, but I just worry that if we try to tackle it all at once, none of it might actually get done....

About the roles, though, @catch wrote:

fyi I mentioned actions/triggers since it's already got a track record for changing states of things in workflow, and because it's an existing API that's already in core.

I'm curious how much you think the existing API can be used here? I'm guessing we can definitely use Actions, but not the Trigger Module itself (since it's not a required module and might be overkill anyway). Instead, the user status changes would have their own very primitive "trigger" implementations. Is that what you were thinking? (I don't know a whole lot about the details of Triggers/Actions myself, which is why I'm wondering.)

@Shai wrote:

Changes in status can also trigger unassignment of roles.

Can you think of a good user interface for that? I worry that it might be a lot more complicated if we allow this possibility too, although for super-extra-flexibility it would definitely be nice... I'm guessing you can get the main flexibility that you need even with just a limited set of options (where a status change can only add a user to a single role but not unassign roles), but I'm not sure... I haven't thought about this in depth myself.

David - extra states - I think we should store sensible defaults, use those various states to determine a sensible default for visibility and/or roles in core, and let contrib handle a UI (for either or both).

actions/triggers - I probably know less about actions/triggers than you, was just an idea, may or may not turn out to be a good one.

@macgirvin: The issue of whether users that have never accessed the site should be visible is the topic of the other thread. If access weren't clobbered, we wouldn't need an additional invisible bit, and not clobbering access is important beyond deciding whether users should be visible or not. That's the topic of #171117: Regression: users without administer users permission can not access user profiles of users that never logged in .

This thread here has a much broader scope, and you're not simplifying if you try to focus this thread on the topic of the other thread.

The "Access Site" permission would be unset in a role and a blocked user would be assigned the role.

If you did something like that now, they'd still have the 'access site' permissions - because roles are cumulative.

@salvis #43

#171117: Regression: users without administer users permission can not access user profiles of users that never logged in is about a regression, caused by a quick hack to solve the SPAM profile problem, which is referenced in the title to this issue -

META-Roles, user registration handling and SPAM registration

We still do not have a viable resolution for the original problem and META-Roles cannot solve it without revamping a lot of permissions infrastructure. This likely pushes it out a number of years and offers no relief to existing sites. We would still need a visibility setting to solve the problem, no matter what roles are built-in/enforced - as it requires a per-user setting on whether or not a profile should be displayed (to the anonymous role). The permissions or role of the person owning the profile aren't relevant to that decision.

Blocking a user is part of the original discussion but not reflected in the issue title. This can be dealt with relatively easily. If one is blocked, they shouldn't have a separate role at all, but merely be prevented from logging in (thereby giving them the same rights as anonymous). On a site with open registration, they'll just get a new login in any case and go back to their disruptive behavior.

Dries has already shown disfavor with a default admin role so that isn't going to fly unless a compelling argument is presented.

So what specific issues are we trying to solve? And is META-Roles the right way to do any of them? I'm interested in solving issues, not generating useless infrastructure.

I'd be -1 any 'negative' permission or 'negative' role - it'd be an absolute UI nightmare.

FYI: http://drupal.org/project/role_login looks like a quite interesting approach for blocking access for users in a certain role. Based on the idea of this module, I could even imagine a simple user permission "allowed to login" (or negated) that can be enabled for various user roles. That would allow for total freedom in setting up a Drupal site and its behavior.

Also: I hereby retract my statement in #7 - I do not believe we need an administrator role. We need far more user permissions instead. For example, our first step after installing Drupal is always the same: Create a "developer" role that has sufficient permissions to install/uninstall modules, alter user permissions aso. and assign that role to all developers.

As Rob Loach says in his comment (#20), why not have designated roles instead of user states? I can think of several use cases for it, not the least of which is to confine blocked users to specific role-based permissions.

Is it still relevant?

The issue proposed to overload the $user->status property with various state constants. Modifying status from a boolean to integer constants.

Originally this issue outlined the following Drupal behaviour for how it determines a "meta role":

Meta Roles

Anonymous Users

• Evaluated by (Drupal 4.7): $user->uid == NULL
• Proposed: $user->uid == NULL)
• Drupal 8: $user->isAnonymous() (Internally: $user->uid == 0). A special anonymous user role exists.

Authenticated Users

• Evaluated by (Drupal 4.7): $user->uid == NULL
• Proposed: $user->status == 3
• Drupal 8: $user->uid != NULL (Internally: $user->uid > 0). A special authenticated user role exists.

Blocked Users

• Evaluated by (Drupal 4.7): $user->status == 0
• Proposed: $user->status == 0
• Drupal 8: $user->isBlocked() (Internally: $user->status == 0)

Administrator

• Evaluated by (Drupal 4.7): $user->uid == 1
• Proposed: $user->status == 4
• Drupal 8: Assign 'Administrator role', this role gets all permissions automatically. Permissions are emphasised over user 1.

Unconfirmed

Role proposed in summary

'Unconfirmed Users' for the users who have just registered but not confirmed the registration using the code that was mailed to them.

• Proposed: $user->status == 1
• Drupal 8: User is blocked (default behaviour), email is sent with activation code, no record is made.

There are multiple ways of doing this in contrib already.

You can choose to assign a role to new users, once they have been confirmed you can remove this role.

Or the inverse, cnce a user activates the account, you assign a role.

Pending Users

Role proposed in summary

"Pending User" is for Confirmed users but whose account must be activated by an admin.

• Proposed: $user->status == 2
• Drupal 8: User is blocked (default behaviour), no email is sent to admin, no record is made.

Conclusion

This issue summary is quite heavy, with no real sense of direction. The two "meta roles" can be discussed in this issue: #426688: Record "pending admin approval" state.

Closing this issue since the 'status' field is clearly boolean.