Add an 'administrator' role to core

As to the Why We Want This:

____

leisa: here's what I think we should do, in human:

a) anonymous - I think we all agree on that
b) admin - someone who can do *everything* - god of the website
c) member - someone who 'signs up' to the website, registers etc.

catch: so those three kind of exist already, kinda.
anonymous = not logged in
member = authenticated user
admin= user/1
But user/1 really is "the first user on the site"

leisa: I can't assign user/1 status to multiple people tho, can I?

catch: not at all no.

leisa: that's annoying. From the user story perspective tho, what I want to be able to do is add someone to my site who has all the same permissions as I do. That's a drama at the moment, yes?

catch: it's a nightmare

so, I think we can do this in a couple of stages.
1. we add an admin role to core.
2. that role gets /every/ /single/ /new/ /permission/ assigned to it automatically.

umm, that could probably be it.

Also, this is one of those steps that brings us closer to 'sensible defaults', where we try and put some of the basics 'everyone' does anyway directly into core itself. I'm not in the IRC chat summary above but was part of it, meaning, I'm in favor of this happening.

The nice thing is that while this issue adding an extra default that some may *not* like, there's this awesome patch that would provide some really nice flexibility to these pre-defined roles: #468768: Remove hardcoded anonymous and authenticated user roles

just want to register my support for this (esp. in light of the discussion we were having around Roles & The Admin Header at D7UX (http://www.d7ux.org/roles-the-admin-header/). I think this will have real usability gains esp. for people newer to Drupal.

I really like this idea.

The patch looks good so far, but I think we then need to make it so that every permission implemented by contrib modules also ends up going to the administrator role.

Another approach, demonstrated in the attached patch, bypasses all access checks if the user has the 'administrator' role in a similar fashion to checking for user #1. Furthermore, I've removed the administrator role from the user permissions form.

It's not perfect (ie, the list of role-specific permissions can still try to set permissions for this role), but I will finish up the details if there is positive feedback on this approach.

Despite the fact that #182023: Add a third default role to core for handling Administrative duties is indeed a bit of a train wreck, the patch here is evolving in pretty much the same direction as the patch there was. The main difference is that the patch here automatically assigns all permissions when a new module is enabled, which I agree is a much better approach -- in fact, it's the exact direction I was thinking I'd take the other issue in before I got frustrated with it and gave up on it for a while :)

Two other things of note:

1. The patch at #182023: Add a third default role to core for handling Administrative duties allows multiple roles to be "administrator", rather than only one. This has some interesting use cases, as well as enabling a UI improvement (or at least what I assume is a UI improvement): You can configure the administrator role while editing the role itself, rather than having to go to a separate random page to do it.
2. In the other patch, I felt like because these roles are very dangerous (new permissions will automatically be assigned to them, sight unseen), it was best to label them specially in the UI somehow. I think my implementation of that completely sucked, but I think the idea behind it was probably sound :)

Basically, I would recommend looking at the latest patch at http://drupal.org/node/182023#comment-1232150 and seeing what code from that can be moved here. It even has some tests written already!!

Catch,

Patch is tested and work great. I like the autocreation of the adminstrator role.

However, the problem I see with this approach is that if the eventual goal is to remove the user/1 special casing, we run into a problem.

Let's say we decide to remove the user/1 special casing altogether, and depend on the 'administrator' role for the administrator. We need to ensure that the administrator cannot lock itself out of the site. Specifically, we cannot allow the administrator to disable 'administrate permissions' permission. For that matter, the site admin shouldn't have any need to remove permissions from themselves as it would serve very little purpose (unless they wanted to declutter their admin menu or something).

The gist of it is that the administrator should have immutable permissions.

I don't necessarily think moving away from user/1 is so far away in the future. However, I will concede to your judgement for now.

With respect to multiple roles, that is something I set up on some sites, and something that would be totally useless on others. Definitely something that should be a contrib... although the for the effort involved in setting up a contrib, you could easily just create a new role or two and click the appropriate permissions boxes.

Please change 'admin role' to 'administrator role' in both the UI and the documentation. Thanks! :-)

Looks good to me, let's wait for the testbot!

Great work people! :)

Just a brain fart: IMO it is simpler/better to make a third hardcoded role next to anonymous and authenticated. This role bypasses all permission checks like user 1 does as suggested in #4. The only other we need to do then is to make sure the role can't be configured and we have the same thing as we have with user 1, but then for multiple users. Giving this role all permissions with hook_modules_enabled() and making it configurable defeats the purpose IMO. That would make it just like any other role while the key is that this role has ALL permissions at ALL times.

You're absolutely right.

I took a look at the patch and it looks great. One might argue we should put the logic to add permissions to a role into a dedicated function, but I'm not sure if that's a gain or a loss looking at the amount of code.

I tested the patch and I'm wondering if we should document this behavior on the permission matrix? Maybe we can make that part of #468768: Remove hardcoded anonymous and authenticated user roles ...

Decided to proceed with this, and to do follow-up work in #468768. Committed to CVS HEAD. Thanks all. Onward!

I have been wanting this for about 8 years. Nice work, folks. I think David's use case for technical/non-technical trusted users is quite valid. I'm OK with leaving that for contrib ... Nice use of new modules_installed hook.

+    '#title' => t ('Administrator role'),

Superfluous space here.

+  // Don't allow users to set the anonymous or authenticated user roles as the
+  // administrator role.

Please avoid abbreviations in comments.

+          db_insert('role_permission')
+            ->fields(array(
+              'rid' => $rid,
+               'permission' => $permission,
+            ))->execute();

Wrong indentation for 'permissions' here.

+  // Assign all available permissions to this role.
+  foreach (module_implements('perm') as $module) {
+    if ($permissions = module_invoke($module, 'perm')) {

Why not simply module_invoke_all() here?

+            'rid' => $rid,
+             'permission' => $permission,

Wrong indendation once more.

...Nice use of new modules_installed hook.

No.. actually not :) That belongs into hook_modules_enabled, because the registry hasn't been updated in hook_modules_installed and this does create ugly issues, for example whith modules that provide node types.

Attached is a patch that does 3 things.

1) To test this, I enabled the forum module in the Enable/Disable tests. Without the fix, it does issue a few exceptions, no actual assertions, not sure if we should add these.
2) To fix this, I renamed user_modules_installed to user_modules_enabled.
3) Now the uglyness happened :) On install, user_modules_enabled does use variable_get('user_admin_role', 0) to verifiy if an admin role has been set. but this does use the value of the "global" drupal install, if not explicitly overwritten. so I had to explicitly reset that value to 0 before installing any modules. Another way would be to disable these hooks as it is done when drupal is installed manually.

A possible way to fix this would be to move module_list(TRUE) and registry_rebuild() from module_enable to drupal_install_modules().

Let's get a CHANGELOG.txt entry for this too, while we're at it.

Hey, this feature was 8 years coming, I think it's worth celebrating. :)

Committed to HEAD. Marking this fixed, as I believe it's done. Will see you guys over at #482346: node_modules_installed() implementation not invoked (located in include file).

The use of array_slice() in user_admin_settings() is problematic due to a bug in older PHP versions. This leads to a number of failing tests: Role permissions: 43 passes, 3 fails, and 0 exceptions

In PHP 5.2.6, array_slice(array(5,6,7,8), 2, NULL, TRUE) generates an array array(2 => 7, 3 => 8), but in PHP 5.2.0 the result is an empty array. It sounds like PHP bug #41686.

This patch uses an alternative method.

I can verify - one of my hosts has only 5.2.0 installed, and I am getting exactly the behaviour c960657 has described.

RTBCing his follow-up patch.

Wow, that's a bizarre bug.

Committed to HEAD, thanks!

I realized that we should probably make sure this administrator role gets assigned to user 1 by default -- otherwise people are going to be pretty confused if, e.g., they create a block that is only supposed to be shown to administrators, but can't figure out why they themselves aren't able to see it.

I would add this to expert.profile as well. User 1 is administrative by definition. However you set up your site, user 1 will be specialized at numerous places when it comes to access control and not having him in the administrative role doesn't really make sense, IMO.

That latest proposal does the opposite: Users will try to remove that role and will be totally confused why the user still has the privileges.

@sun has a point - basically, this is confusing either way :)

Perhaps the real source of the problem is that with the addition of an administrator role to core, we want to encourage people to actually use it (and to leave user 1 as a 'root' account that they use only for emergencies) -- however, they are unlikely to ever do that since we log them in as user 1 right at the beginning.

A possible solution to this problem would be to have the default install profile create two users, assign the admin role to user #2, and log them in as that. They would still get credentials for user 1 (to use when they need "real" root access), but by starting them off with a second account, we'd set things up for them in a way so that they would rarely need to do that.

That would probably be a much trickier patch, however - due to Drupal enforcing unique email addresses per user account, among other things.

Perhaps the real source of the problem is that with the addition of an administrator role to core, we want to encourage people to actually use it (and to leave user 1 as a 'root' account that they use only for emergencies)

I don't see this as the point of this patch at all. And honestly, I think that's a battle not worth fighting. Drupal.org doesn't conform to this standard, why should we to expect our users to? I did try and do this at webchick.net to follow "best practices" and the result is that it's a complete pain in the ass, so I will never do it again on any other site I build. :P

To me, the point of this patch is:
a) a convenience, since most sites will indeed want some variation 'admin' as one of their roles.
b) a security improvement, so that 5 or 6 people don't have to share the user 1 password
c) a UX improvement, since administrators who are not uid 1 won't have to have many frustrating moments of wondering why the new module they just enabled doesn't do anything, only to realize 10 minutes later that they didn't enable "do something" permissions.

In terms of user 1 getting the role, I'm inclined to say they don't, since they're given the powers "magically."

Drupal.org doesn't conform to this standard, why should we to expect our users to? I did try and do this at webchick.net to follow "best practices" and the result is that it's a complete pain in the ass, so I will never do it again on any other site I build. :P

Well, neither of those sites run on Drupal 7! :) The addition of this new administrator role makes it so you don't have to assign new permissions to site admins manually, so doesn't that take away the pain?

In terms of user 1 getting the role, I'm inclined to say they don't, since they're given the powers "magically."

This is true for permissions, but not block visibility. If you make a block that is only supposed to show for site admins, then right now, only 5 of your hypothetical 6 site admins will actually see it.

However, @sun showed that the problem is clearly bigger than I first identified, and it's also not my own personal highest priority to try writing this (I have other patches I probably should be working on...) It deserves its own issue, so I've created one here: #497500: Create an administrator account in the default install profile, separate from user 1.

Fundamentally, this is a usability issue, because we have now introduced this "Administrator" role all over core, so someone administering the site as user 1 would reasonably assume that when they see that, it's talking about them... but it's not :) Another example of this is the permissions page -- if I remove certain permissions from administrators, won't I be a bit confused when I myself still have those permissions?

I am thinking that the best (only?) way to solve these problems is to make it so that people do not ever really have to log in as user 1. In that case, the problem is neatly bypassed.

Let's put this back to closed, and continue any further discussion at #497500: Create an administrator account in the default install profile, separate from user 1, I think.

Since I don't know whether there is another issue for this already, but the recent follow-ups talk about this anyway, I add here:

I think the cleanest approach would be to add some more cruft to core for our "root"-alike user: Hide the role selection options on user/1/edit and output a note instead - to make it clear that this user by-passes each and everything and is treated specially by Drupal.

I'm not sure about hiding the role selection options -- I've seen lots of use cases for assigning roles to user 1 (the block visibility example mentioned above is just one of them), so probably we shouldn't prevent that.

Adding a note would definitely help, but not completely. The bottom of the user/1/edit page is not somewhere people tend to go that often, especially at the beginning. Imagine you have just installed Drupal: During the installation process, you have just been prompted to create an "administrator account", and then next you're browsing around your site and see all these references to the "administrator" role. I think it would take a fair amount of reinforcement/notes to remind you that you, in fact, are not one of those people :)

There is no user_modules_uninstalled() that removes the roles again, causing PDO errors when reinstalling modules.

See also #570572: Change label for user/1 account from "administrator" to "site maintenance account" for further discussion of the usability issues raised above.

I just installed Drupal 7 alpha 5 with the "minimal" installation option (this part may be important - I did not chose the regular option).
When I go to admin/config/people/accounts the "administrator role" drop-down menu only has one option: "disabled"
I created a new account and expected to be able to give it admin power.

Is there something I understood incorrectly? That may be a candidate for usability.

Thanks

The dropdown shows all existing user roles EXCEPT anonymous and authenticated, and allows you pick one to make it the administrator role. Go to the roles page (admin/people/permissions/roles) and create a role called, say, 'administrator'. Then return to admin/config/people/accounts, and you'll be able to select it as the "Adminstrator" role.

can i re-open this or do i need to create a bug against core?

anyway, at the time of 7.7 this feature doesn't do what its intent was.

as a simple example: adding a new node type does not set "administrator" role for all the new privileges associated with this new type.

unfortunate that the admin role project has stated it is deprecated as the feature has moved into D7 core when that module (in D6) does do the right thing.

sweet.. thanks.

Check #1153072: New content types (and other dynamic) permissions are not auto-selected for admin role—always give it all perms
Seems that weirdly enough it's not going to be fixed in D7 :/