Remove hardcoded anonymous and authenticated user roles
David_Rothstein - May 21, 2009 - 03:43
| Project: | Drupal |
| Version: | 8.x-dev |
| Component: | user system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | Favorite-of-Dries |
Jump to:
Description
For a long time I've been wondering if this was possible, and eventually I decided to try writing a patch for it :)
The attached patch removes Drupal's hardcoded anonymous and authenticated user roles and replaces them with a simple system where any role on a site can be auto-assigned to users (a) before they log in, and (b) right after they have registered for an account.
The patch is basically functional and has the following advantages:
- The "anonymous user" and "authenticated user" roles that Drupal currently has are weird and confusing. Why? Because "anonymous" and "authenticated" represent states of interaction with a computer, but most other roles represent categories of people (think "Editor", "Administrator", etc). Things would be much clearer if the roles that users are automatically assigned work the same way as other roles on the site. For example, in this initial patch the default install profile starts off with anonymous users being assigned to a "Guest" role and newly-registered users being granted a "Member" role, but the expert profile doesn't start with any roles at all, and sites are free to use whatever roles are meaningful to them.
- The patch makes it possible to auto-assign the same role for both (a) and (b) above, if you want unauthenticated and authenticated users on your site to share the same base set of permissions. (No more clicking two checkboxes in a row on the permissions page!)
- Some sites have no need for "authenticated users" at all (for example, single user blogs). Currently, Drupal forces that role on them, but this patch means it won't anymore.
- If your site registration policies get more strict (for example, if you previously allowed open registration but then later switched to requiring email verification), this patch allows you to easily separate your users into "before" and "after" by switching the role that is auto-assigned to newly registered users. For example, you could create a new role called "Verified Member" and auto-assign that; you can then safely grant this new role more permissions knowing that anyone who gets it must have gone through more verification steps during registration than users who got the older "Member" role.
- Any patch which involves deleting as much ugly, special-case code as this one does can't be a bad thing :)
Screenshots are attached as well. I think this patch actually makes sense, but it's a big change so someone please tell me where I went wrong with it :)
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| remove_anonymous_authenticated.patch | 33.34 KB | Idle | Repository checkout: failed to checkout from [:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal/drupal]. | View details | Re-test |
| default_install_user_settings_page.png | 99.11 KB | Ignored | None | None |
| default_install_permissions_page.png | 106.53 KB | Ignored | None | None |
| expert_install_user_settings_page.png | 95.19 KB | Ignored | None | None |
| expert_install_permissions_page.png | 70.69 KB | Ignored | None | None |
#1
Note that the following are possible disadvantages or things that still need work:
#2
This certainly still needs work as per the comment above, but I'm very very curious to see what the testbot will say about it...
#3
Wow. Interesting patch. subscribing for now.
#4
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)
#5
@sun: I'm not exactly sure what you mean. Can you give an example?
BTW, I ran the tests locally and it's not as bad as it could be. Got something like 11,000 passes and 90 failures (all the failures were in contact.module, and probably easy to fix). Then it hit the user.module tests and SimpleTest exploded and crashed :) Probably to be expected. So mostly it seems like the tests that this breaks are well-concentrated where they should be, which is a good thing.
#6
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.
#7
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.
#8
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.
#9
Subscribe. And kudos for a well written issue. It helps a lot.
#10
Sounds like we have two states any role can be:
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.
#11
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.
#12
This patch is very interesting indeed. Tracking it.
#13
@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.
#14
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).
#15
This is a great idea. Subscribing.
#16
Another related patch that has been committed: #480660: Add an 'administrator' role to core
#17
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: make roles admin look like content types. 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
#18
Interesting, subscribing.
#19
subscribe
#20
Think this is well worth it - subscribing
#21