UID 1 and the lack of the proper Drupal Admin Role

[DiegoPino]

What is this?

Mostly a question (for @pcambra) and a fact that leads to unexpected behavior on our Drupal 9 deployment.

Background

In Drupal 9, the "standard" install profile is gone (correct me if so) and to be able to start a site using a stored config/sync folder we went for "minimal" profile. After deployment I noticed that a few Webform Elements and Wizard pages were totally removed for the Admin user but not for the Demo user (weird!) and after typing (but not submitting) a LOOONG bug report I noticed that it was actually a combination of how "Drupal 9" handles the User ID 1 (initial one given during drush si) and how Webform checks for Administrative privileges.

• Basically UID 1 has no role assigned. It is just a special, exceptional, user that bypasses checks. But also means you can not check for its role as a conditional to know if it has admin privileges (as one may be tempted to do if you think that every User (equality/democracy) is handled the same way code wise.
• And Basically also, Webform module uses Access Checks for Roles and Elements: Anonymous, Authenticated, Administrator and then all the rest of the custom roles. happens that if you check Administrator, UID is considered not part of that role (of course) and we get this strange behavior.

Solution: The hack solution was ,during the D9 deployment instructions, to add an extra command where admin gets the proper role assigned via drush. But to be honest, it all feels strange to me, inconsistent to what to expect from Drupal. I also feel maybe Webform Module 6.0 may be a bit culprit assuming this special UID1 behavior is something that may be expected.

I will leave this here for @pcambra because he probably already has an explanation (PS: I know he has!) and we can all learn a thing or two from that and plan ahead too when dealing with the Admin user.

[pcambra]

Just as preliminary notes, the UID 1 is still a thing in Drupal 9, here's the long term issue about it https://www.drupal.org/project/drupal/issues/540008

Since this change request (8.5+), there's a flag in roles "is_admin" that is added to the config entity for a role: https://www.drupal.org/node/2444095

The standard profile comes with this content in user.role.administrator.yml

langcode: en
status: true
dependencies: {  }
id: administrator
label: Administrator
weight: 2
is_admin: true
permissions: {  }

However, the minimal profile does not include such a file, and thus no roles (admin or not) are created. I'm not familiar with this part of the code specifically or how we install but if we want a different "flavour" (I know we like flavours around here), I think we should consider creating our own archipelago profile.

[DiegoPino]

@pcambra thanks, this helps.

Our user.role.administrator.yml is fine. We provide it via the config/sync folder, the issue is that UID1 gets no role assigned by default. Basically instead of a profile,we have a full sync folder (so only the hooks missing, maybe that is set by a hook??)

See https://github.com/esmero/archipelago-deployment/blob/1.0.0-RC1D9/config/sync/user.role.administrator.yml

Also, do you know why the "standard" profile changed from Drupal 9? Can not be used with a config/sync combination? I tried all my tricks and could not use the standard one + a config/sync folder.

I agree that writing a quite minimal but not as minimal profile could be an option for Archipelago. I fear it will add some maintenance overhead to us, given that we also have to manage config/sync and composer itself, but we can do that.

Note: https://www.drupal.org/docs/distributions/creating-distributions/how-to-write-a-drupal-installation-profile

Finally, do you think that https://github.com/esmero/archipelago-deployment/blob/1.0.0-RC1D9/docs/osx.md#step-4-create-a-demo-and-a-jsonapi-user-using-drush-and-assign-your-admin-user-the-administrator-role-new-for-drupal-9 is enough in the meantime while we prepare RC2?

Thanks!

[pcambra]

@DiegoPino There's a drupal site-install --existing-config as well, are we using that? See: https://www.drupal.org/node/2897299

"La ignorancia es atrevida" so I would jump in the water and say that maintaining a profile -in my mind- would be a better practice than having to keep config in sync on every release? https://www.drupal.org/project/config_devel and https://www.drupal.org/project/config_update are good travel companions for this. But I'm fully aware this is a paradigm switch, we move to distro waters and that's a bit of a different game.

Re: if it works, there's nothing wrong in having documentation but this is something we can automate.

This is what the standard profile does:

function standard_install() {
  // Assign user 1 the "administrator" role.
  $user = User::load(1);
  $user->roles[] = 'administrator';
  $user->save();

vs the minimal profile that does literally nothing as the install was removed https://git.drupalcode.org/project/drupal/-/commit/8dc500997040cc3bde8a8e93f37f9bd4317425b3

[DiegoPino]

@DiegoPino There's a drupal site-install --existing-config as well, are we using that? See: https://www.drupal.org/node/2897299

Yes, since D8 and still I D9. But previously you could combine that + a profile. No longer.

"La ignorancia es atrevida" so I would jump in the water and say that maintaining a profile -in my mind- would be a better practice than having to keep config in sync on every release? https://www.drupal.org/project/config_devel and https://www.drupal.org/project/config_update are good travel companions for this. But I'm fully aware this is a paradigm switch, we move to distro waters and that's a bit of a different game.

I agree. Issue we could find is how to deal with all the many user (users!) provided changes that will mess up profiles (more like our profile may mess their changes) when they decide to upgrade from 1.0.0 to 1.1.0. I have to be honest, configuration managment is something in understand and use, but not a workflow I have managed to document correctly for the "upgrading a highly customized" archipelago yet. I will add the profile idea to 1.1.0 as an ISSUE

Re: if it works, there's nothing wrong in having documentation but this is something we can automate.

This is what the standard profile does:

function standard_install() {
  // Assign user 1 the "administrator" role.
  $user = User::load(1);
  $user->roles[] = 'administrator';
  $user->save();

Oh, gosh, as suspected, there it is!

vs the minimal profile that does literally nothing as the install was removed https://git.drupalcode.org/project/drupal/-/commit/8dc500997040cc3bde8a8e93f37f9bd4317425b3

[pcambra]

@DiegoPino I think this might be related to https://www.drupal.org/project/drupal/issues/2788777 and https://www.drupal.org/project/drupal/issues/2982052, so if a profile implements a hook install, seems it cannot be installed from configuration, I think we end up in the same place of having a small install profile and move the config install/optional/etc to that profile, that would save some install steps and make everything more consistent.

Regarding managing config in highly customized distros, I hear you, I think at some point there is a fundamental difference between the simple workflow, which is those that are using archipelago ~ as it is and those who install and configure the site massively. The first can be handled via config_update workflows, however, the latter are a giant question mark to me, do we have specific update flows for them in specialized modules? are there common use cases?

I'm on a distro group (#distributions on slack) and config management is one of the major pain points out there. On the other hand, CMI 2.0 will be an official initiative moving forward, so there's that.

[DiegoPino]

@pcambra I will put our own profile in the 1.1.0 release target (ISSUE). We may want to test upgrade scenarios and at least document the basics (and the expected annoying results people may get) if they Sync Configs (partially). Thanks for this. It helps a lot, at least we are not alone!