Create an administrator account in the default install profile, separate from user 1

No, I don't see how this is in anyway more user friendly? It's basically a work around because we don't want to assign user 1 to role administrator?

I don't think it does, since assigning the role to user 1 makes them able to do things. If we introduce something that prevents them from doing things, and instead require them to learn - we are in the wrong direction.

A drupal_set_message on the permissions page would help with the confusion. If you're logged in as user 1 and you remove permissions from a role assigned to user 1, you could get a message letting you know that you're the superuser, so you still have those permissions. We do something similar with themes. If you've set RootCandy as your admin theme, and then you go to admin/build/themes and change your site theme to Garland, you get a message letting you know why the page you're on is still in RootCandy.

Why not ditch the special casing for user 1 instead? It is an arbitrary holdover that shouldnt be necessary anyway with a "Administrative User" role. Just prevent the deletion of the last administrative user to make sure you don't lose administrative capability of the site. Then assign user 1 to the admin role like you would for any other admin and all admins are equal.

Ok so i see 2 real options here for improvement and I'm willing to help implement any of them. I think that the "special user 1" constraint goes against everything we are trying to tell our users about how permissions come from roles not users so I'd prefer to ditch the special casing of user 1. THis also happens to solve the main concern of this issue. Here are the options as i see them:

1. Administrative user role is provided by default on install. It is hardcoded to pass all user_access() checks just like user 1 was and the checkboxes in permissions are disabled. The name can be changed but it cannot be deleted.

2. Administrative user role is provided by default on install. Its permissions, set by the permissions page are respected like normal roles excepting the "administer permissions" one which is disabled. New permissions are automatically enabled as they are now. The name can be changed but it cannot be deleted.

I'm coming to this issue from #46149: Prevent account cancellation for uid 1 (at comment #111) Seems to me that the issue I'm currently reading here is trying to stop the automatic logging-in of new site owners as uid1 and instead log them into a user with decent admin perms, but not the root user account. This is a lofty, difficult, yet worthwhile goal.

Let me share my thoughts about Michaelfavia's suggestion in #5 and #6 where he says:

Why not ditch the special casing for user 1 instead? It is an arbitrary holdover that shouldnt be necessary anyway with a "Administrative User" role. Just prevent the deletion of the last administrative user to make sure you don't lose administrative capability of the site.

Michael, an 'administrative' user is not necessarily god-of-the-site. Sure, it *could* be that way, especially in single user blog sites, but as soon as you start making 12 to fifteen roles for your site, and placing Site Administrators (the 'administrator' role on more sites that you can count) in charge of "everything but the stuff they shouldn't be touching", things will fall apart. For the sake of argument, "everything but the stuff they shouldn't be touching" excludes user permissions and the php filter. Those things were preset by the site's developers using the root user account (uid1) during construction of the site, and handing those settings over to the administrator role would give 14 people who know nothing about user permissions the ability to wreck the site.

Sure, you *could* claim that the 'administrator' role was never designed for such a purpose, but consider this. There's more than one site out there that is currently using the 'administrator' role for the exact purpose outlined above, and if you try to make this role into a root user or superuser role, you'll have a lot of peeved people come upgrade time.

I'm -1 on removing uid1's special casing. It's there for a reason, it's the only way to ensure that the owner of the site doesn't get locked out of their own site by fiddling with the site's settings. Let's pursue the idea set forth at the top of this issue and see where that takes us.

-1 for me. I'm not sure how creating two separate users could possibly be helpful. For the developer, it's more of a nuisance than anything, and for the DIY blogger, it's just another layer of confusion.

-1 From the developer, as it creates another nuisance.

-1 From the DIY blogger, as it adds another layer of confusion.

-1 as it requires two seperate email addresses, creating both nuisance and confusion.

also, i like to have a root user (keeping the special casing of user/1) on my system, since i can use it when stuff goes wrong^TM.

Thinking from the stand point of the DIY Blogger, is there a way you could include in the installation a request for a User Name (Name you want your content to show as posted by). With the text explaining a bit about the Site Maintenance Account (user 1), and that the User Name account will be an Administrator with the Administration role, and the name under which all content would be added when logged in as this user. That this account becomes their user account, and can be used to do anything they grant to the Administration role. That the purpose of the Site Maintenance account is to be used solely for advanced site building and configuration, as well as maintaining the site. Possibly the option might want to be added that they would be asked if they want to logout of the Site Maintence account, and login as this user to begin adding content.

I agree that this account would have to allow for a duplicate email address (some people only have one), and would be automatically created based on the answers provided, including a request for a password for this account.

Personally I feel that without adding more information or outlining steps to get an "administrator" user, the whole Site Maintenance account is going to confuse people as much as referring to it as user/1.

@WebWeaver64
you are confusing me, could you clarify yourself?

@David Rothstein
I don't think we can/want to create sudo (yet) in drupal ;)

also, this will not be in D7, we've entered code slush already.

In the current D7 installation on the Configure site screen, you're asked to provide a User Name/email/password for the Site Maintenance account (I'm going to skip over my issues with this whole things).

What I'm suggesting would be:

Site Maintenance Account:
The Site Maintenance account is to be used solely for advanced site building and configuration, as well as maintaining the site. This account is granted permissions automatically.
User Name:
Email:
Password

Administrator Account:
The Administrator account is to be used for your daily administration, and entering content. This user is granted all permissions given to the Administrator role. This account is granted permissions based on their role as an Administrator
User Name:
Email:
Password

Once installation is completed they would be presented with a page that said:
Continue creating your site (you will be signed in with the Site Maintenance account)
Start adding content (you will be signed in with your Administrator account)

This right here lets them know with no confusion that they have two different users, and that they have different uses and permission, and that one user (user2) has permissions based on the Role Administrator, and that those permissions only apply to user 2. That the suggestion here is to use User2, for creating content, and User1 is for "building" the site. As it isn't saying anything about a role for User1, it suggests that it doesn't have one, which it doesn't need.

I think this can only happen when it is done trough the install profile.
while i can (partially) agree with the ability to (optionally) create this (secondary) account in the default install profile, i certainly DO NOT WANT this to happen in the expert profile (or a single-user blog for example.)

Maybe I'm missing the point of all this user1 stuff. I thought the whole idea behind it was to stop new users from using user1 for everything even in a case of a single-user blog. If that isn't the case then why rename it? If you're not a new user, and only want to use user1 then you delete user2 because you understand what your doing.

Telling people that the user1 isn't really just a Site Maintenance account, now becomes another explanation when there shouldn't be a need for one imho. Either the standpoint is that it shouldn't be used for daily administration and content, or it doesn't really matter. In which case why rename it, leave it as a suggestion they can find out about if they care to read about best practices.

Id like to clarify that my solution to this problem was to get rid of any special consideration for user 1 and make permissions soley dependent on the "administrative" role instead. Then just make a simple check to make sure that there is at least one user with the administrator role remaining when a user is being deleted. If so let them do it. If not either prevent them or tell them they are responsible for the effects of doing so.

I dont know why this isnt an elegant solution to the problem. It gets rid of special casing code (always a plus) and makes roles the true arbiters of permissions as they are in the rest of drupal.

first of all, even linux still has root (altrough some distro's have sudo, and a non-acessible root, you can still gain access to it when needed)

secondary, there are currently AFAIK only a couplecases where you would need to verify weither a certain account/user is user/1
- destructive actions on users.
- inside premission functions.
- certain caching situations.
- maintaince tasks. (update etc.)

hardcoding a certain role v.s. a certain user to pass all permissions in in my opinion less secure, and needs more special casing code.

The linux setup has very little relevance here imo. Most have removed the root user in favor of a sudo solution anyway.

That aside the determination of whether a user is "user 1" occurs everytime a permission is checked not just in the special cases you mention. But that wasn't the point either. The point was to enable multiple "user 1's" so that development and administration teams are no longer "separate but equal" when it comes to managing sites. It also makes explaining who gets what permissions much easier when you dont haver to explain special cases to new site owners, etc. it generally just simplifies stuff.

Most have removed the root user in favor of a sudo solution anyway.

I've never seen a linux dustribution where sudo su didn't give me access to the root account. (not to mention, when you give root it's pass back, it's fully back in action) ;)

the determination of whether a user is "user 1" occurs everytime a permission is checked

which would be 1 function: user_access() which i specified as

- inside premission functions.

on the other points, i think that can be solved by some additional (non-sledgehammer) permissions.

the best way would be, if you make user/1 once, and after giving another user enough (or all) permissions, can put the (ridiculous long) password in a firesafe, and never need it anymore.

To me this is 100% clear: michaelfavia is right. Having a "superuser" is simply less secure, regardless of whether linux does it or not. It necesitates password sharing (sudo or no, everyone keeps their linux root passwords somewhere) and accounts that don't pertain to an individual. Are these practices not universally considered bad security?

One slight alternative to michaelfavia's solution: instead of counting how many administrators are left before deleting, add one fixed rule: only administrators can delete administrators. Simple.

I think breathing some life into this might be a good idea.

Logging (new) users as user 1 is encouraging bad practice. Special case user 1 is there, I don't see it going away, and if it did it's a whole other question. However, making people use that as their first experience is just either creating additional work for them, throwing a bad User Experience at them, or/and encouraging them to administer the site from that user account.

We consider it best practice that you should make another user, and administrator role, but that's not what is encouraged by the process. Why not make these both automatically? A work around for the e-mail address might be required, or alternative made - but users have that problem already if they aren't always to use user 1.

Now, instead we throw the whole user 1 experience, permission to do everything, on potentially first time user administrators. Then we expect them to RTFM and create users and roles before they do anything else of interest.

Better: Offer up user 1 user name and random password; and
user 2 where the user picks the name, and password and it gets assigned a created administrator role (with assign permissions role), but not all permissions.

Better still: Have the installing user choose what level 'beginner', 'intermediate', 'advanced' permissions the administrator role should have. Then new users aren't thrown into the confusing situation of being able to do all the things, but not knowing where to find the first thing; and advanced users aren't thrown into a dumbed down interface where you have to jump hoops to get to all the things.

Hello All,

I do agree with Ekes that we need to create user 1 and administrator role in installation.

I have installed Drupal 8.6 and while installation I have selected Minimal profile to install instead of Standard profile.
But after site gets setup I dont have permision to add new Roles here.

I tried to update me (as I am user 1 here) and tried to assign "Administrator" role, but unfortunatly there is no pre-defined role.

When I clicked on "User-interface" I got a message that "You do not have any administrative items.", but basically I (as user 1) don't have permission to add those.

Marking this as outdated because the usecase for this will no longer be needed once #540008: Add a container parameter that can remove the special behavior of UID#1 is committed.