Explain in the user interface that user/1 and the "administrator" role are not the same thing

Thanks David. I think this would be a good place to consider how all these pieces fit together. The basic issue has been in drupal for a long time. To wit...

"It is not obvious and clear from the UI that permissions simply do not apply to user 1."

I remember when I first started using drupal back in 4.7 that the first few times I went to the permissions screen I was confused about "which of these things will take away my user 1 permissions by accident and lock me out of my site". It didn't take too long to figure this out, but it was definitely an issue.

Adding a default administrator role (while continuing to call the first user admin) exacerbates this issue. It will be natural for the user to think permission changes to this administrator role will apply to the first user they created as well. Where and how do we tell them that this is not so?

There are a number of ways to address this. One is to start with #570572: Change label for user/1 account from "administrator" to "site maintenance account" to indicate to the user right in the installer the special nature of this first user. Another is to look for places in the UI where a "set message" can essentially "smack" the user and remind them of the nature of user/1. Another option David doesn't explicitly reference above is to improve the documentation of the special characteristics of user/1. This could be both in INSTALL.txt as well as in the installation guide in the handbook.

I'm not sure that assigning user1 to the administrator role is productive here (which was the third possible solution above), especially since we're telling the user that it basically doesn't matter which roles are assigned to user1 and then we went ahead and assigned a role by default. Comes across like a contradiction.

That being said, I'm not necessarily AGAINST it, per se, I just think it would have to be explained very clearly.

(that was a subscribe in disguise)

I agree with @mcrittenden. Assigning user/1 to a role implies that that role controls user/1's permissions when we know it won't for drupal 7.

On the other hand, @David_Rothstein brings up the block visibility issue. There is definitely a potential for a wtf moment here for the user where they have assigned block visibility to the new administrator role, but then don't see the block while browsing the site as user/1.

The quandary is that we can avoid the wtf moment regarding block visibility for the user by automatically assigning user/1 to the new admin role, but we create the potential for a very different wtf moment when the user modifies permissions for the administrator role and thinks they will apply to user/1 when in fact they won't. At a practical level, we also have to deal with the fact that the minimal install profile doesn't even create an administrator role to which to assign user/1!

Ideally, I think this issue would be a good place to discuss what mix of modifications to d7 + user interface help text (or set messages) + well defined doc handbook pages would serve to educate the new user to understand the role/permission system while also understanding the special characteristics of user/1 with the fewest possible wtf moments for the new drupal site maintainer.

So here is my initial stab at this...

Suggestion
1. Modify the label in the installer to be "Site maintenance account" as per #570572: Change label for user/1 account from "administrator" to "site maintenance account"
- makes a start at suggesting the special nature of user/1 especially in regards to upgrade process and best practice
- allows us to avoid a lot of verbiage trying to explain our way around how the "administrator" account created during install is not controlled by the administrators role and in fact is entirely unrelated.

2. Create a well defined handbook page that describes the role and permission system, the concept of an administrator role, and highlights the special nature of user/1 (site maintenance account). This page would be an excellent place to describe some best practices around user/1 for different types of sites where the issue of block visibility by role can be mentioned.

3. Add help text to direct users to this handbook page from "admin/config/people/roles", and "admin/config/people/permissions", and possibly from "admin/config/people/accounts" (under the Administrator Role assignment fieldset).

4. Add some text to the INSTALL.txt (and possibly UPGRADE.txt) which very succinctly describes the role system and special handling of the site maintenance account (user/1) and also points the user to the well defined handbook page on this topic described above.

Justifications:
1. Why not assign user/1 to the administrative role automatically?
- It implies to the new user that modifications to the administrative role will affect user/1 when in fact they won't. I think that creates a much greater wtf moment for the user than the block visibility issue.
- The administrative role is not created using the minimal install profile so it would also be complicated to implement perhaps...

2. Why not use set message on the permissions screen to tell the user that their changes don't apply to user/1 when they make changes to permissions for a role to which user/1 is assigned?
- To me this gives the impression to the user that "something is wrong".
- I think it is overkill if we have documented this behavior elsewhere
- I think it is reasonable for us to expect that a user with a more than trivial site will read the docs on roles and permissions if we point them to it from critical points in the UI.

3. Why not create a second account during install to assign to the administrator role separate from user/1 (as per #497500: Create an administrator account in the default install profile, separate from user 1)?
- This would be a major hassle for many users especially for users who are creating simple blog sites, etc. The need for them to have to have multiple email addresses to supply at install time is too much.

Conclusion
I think my suggestion still leaves open the potential wtf moment for the user when they assign a block to be only visible to the administrator role and find that user/1 doesn't see it. However, how this would affect users will depend a lot on the site. For example if someone truly uses the site maintenance account (user/1) just for upgrading and installing modules, then this won't really be an issue for them. If the user decides that they have a very simple site and would rather just use user/1 as a regular account then our handbook page should recommend that they assign the site maintenance account to the administrator role. In other words, this will be a site dependent issue that should be well documented rather than "hard coded" into the UI.

@David_Rothstein, so I took a look where this hits in the UI. Also, I'm attaching two screenshots with the red box highlighting the change your patch makes. It should be noted that at the moment the patch adds the highlighted text in both cases ONLY if the currently logged on user is user/1.

I'm not yet convinced about adding user/1 to the administrator role automatically. There is nothing stopping the user from adding user/1 to the administrator role if they decide to use user/1 as a day to day admin account as well.

Also, I would ask to consider why was the administrator role added to core (at least in the default install profile) in the first place? My understanding was that this was to encourage the use of day-to-day admin users separate from user/1. Providing an administrator role that automatically receives all new permissions makes it much more attractive for the user to NOT use user/1 as a day to day admin. By now assigning user/1 to the administrator role we water down that message.

I'm making the "anti" case for assigning user/1 to the administrator role automatically. That said, I don't think it would be a disaster to do it. Either way we'll need solid docs (and maybe help text) to further explain what is going on with user/1.

I think the whole user/1 and assigning it to the administrator role is confusing, and roles should be blocked from being assigned, stating that user/1 is a special user, and has access to everything. If you want to apply a role, add a user. Either it's special or it isn't. Every exception you make brings in more confusion.

@ David_Rothstein, can uers1 be blocked from something? I guess I'm not clear on that. If you assign a role to user1 and block that role from something is user1 blocked from it?

From what I've understood about user1:
They have access to everything.
From a best practice perspective, this user should only be used for maintenance.
That this is a special user.

If you want to make it understandable that the role assigned isn't the same as the permission given to this user automatically, then you need to keep them separate.

If you assign the role administrator to this user the assumption is that anyone with that role is going to have the same abilities, and that just isn't true. It's a simple If Then. If I'm an Administrator, and I give someone else that same Role Then they will have the same access. This however doesn't return a true statement.

The whole point I'm trying to make with my suggestions is that the user1 is now called a "Site Maintenance" account. Either roles apply to it or they don't. I believe what is happening is causing more confusion for the new user then less. Either the account should be used special case or it shouldn't. Each exception just leads to more confusion for the new user. Which I thought was the whole point of making these changes. Either the idea that there is a user that is used for maintenance and not for something else is valid and what the POV is going to be from a Drupal standpoint or you might as well leave it as it is, and not have it renamed.

You understand that Roles and Permissions are two totally different systems, does the person just starting? Or do they believe that the role they assign to a user gives them permissions?

imho most new users are going to be assigning permissions based on a role, and thinking from that perspective.

What I was trying to understand was if I assign a role of Administrator, and then block visibility to that role for a page, would User1 still be able to access that page? I don't fully understand how permissions and roles are different other then individual permission grants, and my basic understanding of what user1 is. I thought nothing effected the abilities of user1.

And my "bug" report - #1072226: "Use the administration toolbar" permission have no effect for the Administrator role - also shows that people still get confused. (Thx, David, for pointing me to this thread.)

To me the most important fix is to display a message on the permissions page so I understand/remember that the administrator permissions don't affect user 1.

I opened the issue (#1239654: Overlay ignores admin permissions) listed above (http://drupal.org/comment/reply/572240/4865900#comment-4865900), and I want to point out that there is nothing in the user interface to indicate that user 1 has any kind of special permissions. Editing the user profile has the exact same options as any other user, and it stands to reason that applicable role permissions would take effect. I think user 1, or any user that is *not* affected by the permissions (accessed from people->permissions in Drupal 7), should *not* have role settings available to it.

So would it be a more global (better?) fix to have a consistent indicator shown that you are logged in as user/1?

So would it be a more global (better?) fix to have a consistent indicator shown that you are logged in as user/1?

I think so. Specifically a consistent indicator that you are logged in as a user that is not subject to permissions. Perhaps a "super user" status? IIRC you can set the permissions for this user but they don't apply (all permissions are always granted regardless) and there is nothing in this process to let the user know about the discrepancy.

Marking as outdated, because: no activity in years and this may no longer be needed once #540008: Add a container parameter that can remove the special behavior of UID#1 is committed.