Remove hardcoded anonymous and authenticated user roles

Wow. Interesting patch. subscribing for now.

drupal_anonymous_role() and drupal_registration_role() always need to return values, because there is a certain amount of functionality that depends on it. (mostly in contrib modules)

Interesting patch. Removing the hard-coded "authenticated user" role makes a lot of sense. On the other hand, removing the hard-coded "anonymous user" role only makes sense if we could dynamically add a role to an anonymous user, which is currently impossible. This would be truly awesome, as it would mean that we can do some kind of segmentation between anonymous users.

Love this idea. Anywhere you really do need a check for "is this user logged in or not?" you can just use $user->uid == 0, so I don't think David's first point in #1 is actually that much of an issue.

I really like this. For a while I've been thinking about use cases like giving every user a role on registration, but taking that role away again if they abuse the site (but don't necessarily do enough to warrant blocking). This would allow that out of the box without any nasty hacks.

Subscribe. And kudos for a well written issue. It helps a lot.

Sounds like we have two states any role can be:

1. Authenticated
2. Anonymous

According to Dries and Catch in the discussion going on over at d7ux.org: Admin Header, we may need to add one more state: Administrator.

I believe this is what #182023: Add a third default role to core for handling Administrative duties is all about. I will be cross-posting there.

What does a site look like to a user without any role? Can she view any content? Or, well, view or do anything at all?

I can see why it could be useful to give the same role to both logged in and not logged in users, but I don't see how it's a good thing to make it possible to have users without any role at all.

This patch is very interesting indeed. Tracking it.

@zirvap - if you remove all permissions from anonymous and authenticated users, then they can't access anything anyway, so there's really no change there.

Perhaps offtopic, but related:

The {users_roles}.tid column exists in Drupal's schema and was supposed to allow tagging of user roles (which was never implemented).

This is a great idea. Subscribing.

Another related patch that has been committed: #480660: Add an 'administrator' role to core

I attempted to remedy this same problem with a much less powerful but also much simpler solution. i made the names of the roles editable and added descriptions to the roles #393406: "Edit" links on roles admin page are confusing to users: "Edit permissions" should be the primary link. While i put all of my weight behind this patch instead, i would like to offer it as a partial solution if your isnt generally acceptable by everyone. It solves the first part of your issue but fails to offer the same benefits of the rest which I personally find valuable.

I do have a small concern with hiding all of these options under "site settings > user" though. I would never think to look there and i know my users wouldnt. This is why i advocated moving user settings under a menu local task for admin/user/user #391412: Move contact form, post, and user settings below Site configuration (original title was: Move "user settings" under user as a local menu task) and role settings under roles (admin/user/roles). This is inline with putting the configuration of items in place with the items they modify. We are exacerbating the "i have to go all the way across my site to change a setting for roles when I'm already in roles section".

i realize that nobody likes the menu local tasks because of issues with visibility, etc but I think we can mitigate/fix those with decent design, the new admin bar (with hierarchy), and add child links below admin menu items in some similar fashion to: http://drupal.org/files/issues/screenshot1_0_5.png

Interesting, subscribing.

subscribe

Think this is well worth it - subscribing

Subscribe

sub

Very interesting; tracking.

_{Help fix "+1 subscribe" posts: see http://drupal.org/node/34496 and http://3281d.com/2009/03/27/death-to-subscribe-comments}

More than two years without activity... Is this still relevant, or blocked by some other issue?

Still relevant. I don't think blocked on anything else, it needs someone to pick it back up and reroll the initial patch from git.

Here's a reroll of the original patch together with some additional changes for code that was introduced since the previous patch. The main difference is that the standard install profile will create anonymous and registered roles while the minimal one comes with no roles.

I still need to work on this because it doesn't remove the roles from the tests. They are being used in several tests for checking functionality for anonymous users that involves permissions assigned to the anonymous role (e.g. posting comments).

As was originally stated by David, this is a tough one to implement and has a possible issue. Right now the registered role gets assigned automatically to new users. How do we handle existing users or switching the role? I was thinking of two ways:

- Always assign the role on user load instead of assigning it in the database. This might be an issue if we want tighter control over users and want to be able to remove the role from a single user.
- Provide an option for a batch job to run when the role is changed, assigning the role to all users. This introduces additional problems like removing the previous registered role and it's not great for sites with many user accounts.

Personally I'm in favor of the first option. It basically functions like the authenticated user role used to work and it doesn't introduce any messy things like having to run batch jobs. If having tighter control over the roles is an issue there's always the possibility to override or remove the role on hook_user_load for modules.

Any thoughts or suggestions on how to tackle this?

Also, any ideas on making tests relying on the roles compatible with this? Should the test profile always create these roles?

Sending to the testbot.

#28: remove-hardcoded-roles-468768-28.patch queued for re-testing.

Possibly related (and may be able to be incorporated into this patch): #749298: Anonymous user name should be used on permissions screen

This issue #479708: Rename 'Authenticated user' and 'anonymous user' so they are clearer is stopped by this one.