Problem/Motivation

In Drupal 9.3.0 the administration role setting got moved to the new role settings form (see #987978: Move "administrator role" setting to new Role Settings form). Problem is on the permissions page (admin/people/permissions) the user_help text still points to the old location, the Account settings page.

the user help text on the permissions page

At the same time the description of the select box on the role settings page is incorrect and is creating a false expectation.

the role settings page

This role will be automatically assigned new permissions whenever a module is enabled. Changing this setting will not affect existing permissions.
The statement that changing this setting will not affect existing permissions applies to every role except the administrator role. Problem with the administrator role in the standard profile - on install it is set as the administration role and every checkbox is selected. If you change now the administrator role on the Role settings page the permissions of the administrator role get reset to its defaults. If you take a look at the default permissions assigned in the standard profile: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/profiles/sta... it is clear why after changing the administrator role on the role settings page all checkboxes are unchecked. Since the administrator role is the role that is assigned initially for the standard profile install and changed later on it is a potential source of confusion and problems.

Steps to reproduce

1. Go to /admin/people/permissions and read the user_help text
2. Go to /admin/people/role-settings and read the description

I've checked in Drupal 9.4.1 and Drupal 10.0.x-dev. The problem applies to both versions.

Proposed resolution

1) Change the link from admin/config/people/accounts to admin/people/role-settings. And the least invasive update to user_help text could be:

From the Account settings page, you can make any role into an Administrator role for the site, meaning that role will be granted all new permissions automatically.

changed to:
On the Role settings page, you can make any role into an Administrator role for the site, meaning that role will be granted all permissions.

Screenshot of the permissions page with the applied changes

2) Based on the discussions in #3306259: Drupal Usability Meeting 2022-09-02 the consensus was to extend the scope of this issue and change the string on /admin/people/role-settings from

This role will be automatically assigned new permissions whenever a module is enabled. Changing this setting will not affect existing permissions.
to
This role will be automatically granted all permissions.

administrator role field set on the role settings form with an updated description stating that this role will be automatically granted all permissions

That way it is in line with the user help text. The second sentence gets removed as well as the word new and the verb gets adjusted from assigned to granted which is in line with the user help text.

Addendum:The issue here and the one I will link later on was discovered and discussed during the Drupal Dojo in Austin over the course of two or three consecutive weeks. It would be good if someone could provide @cutehair and @rocketeerbkw an issue credit since both helped discovering and understanding this and the other issue.

Issue fork drupal-3293855

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rkoller created an issue. See original summary.

rkoller’s picture

rocketeerbkw’s picture

Assigned: Unassigned » rocketeerbkw

The Austin Drupal Dojo is working on this issue tonight.

rocketeerbkw’s picture

Assigned: rocketeerbkw » Unassigned
Issue summary: View changes
Status: Active » Needs review
FileSize
173.36 KB

We discussed the issue and proposals as a group. We decided to go with Option B: Change the link. We also updated the text to say that the Administrator role is granted all permission, not just "new" permissions.

Screenshot of the permissions page with the applied changes

We decided against Option A because we think there will be changes in the related issue #3293874: Prevent accidental lockouts on the Role settings page and clarify the corresponding description for its select box. Option B allows the broken to get fixed ASAP while further discussion happens in a bigger, potentially more complicated issue.

Participants were: @rkoller, @rocketeerbkw, @cutehair, @Arctic.Cheetah, and Diana

cutehair’s picture

Our Dojo worked together to remedy this bug.

AaronMcHale’s picture

Issue tags: +Needs usability review

This would be a good issue to work through at a UX meeting, so tagging for review.

Queued for review at #3300912: Drupal Usability Meeting 2022-08-05 or a future meeting.

rkoller’s picture

We've discussed the issue at #3306259: Drupal Usability Meeting 2022-09-02. It will have a link to the recording and transcript of the meeting. For the record the attendees at the meeting were @AaronMcHale, @benjifisher, @DyanneNova, @shaal, @simohell, and me.

There was consensus about going with Option B and the suggested changes to the user help text - updating the link and removing the word new. The group then agreed to extend the scope of this issue and also include the update of the description on the role settings page currently in the scope of #3293874: Prevent accidental lockouts on the Role settings page and clarify the corresponding description for its select box. So this issue will be extended to be about the update of all micro copy related to the role settings feature. The suggestion the group agreed on was to remove the word new and remove the second sentence Changing this setting will not affect existing permissions..

I will update the issue summary and title of this issue after posting this comment. @benjifisher suggestedin a brief followup conversation on slack not to update the issue summary and title of the other issue (#3293874: Prevent accidental lockouts on the Role settings page and clarify the corresponding description for its select box) yet and instead just leave a brief comment on the other issue. he recommended to make the changes as soon as this issue here is fixed.

rkoller’s picture

Title: The user_help text for user.admin_permissions is outdated » Update the outdated user_help text for user.admin_permissions and the description of the select box on the role settings page
Issue summary: View changes
FileSize
145.57 KB
Anchal_gupta’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
158.41 KB
462.76 KB

Applied MR #4 on 10.0.x. The help text has been updated after applying this MR #2485.

rkoller’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: -Needs usability review

Forgot to remove the needs usability review tag in my last comment. apologies.

@anchal_gupta and i am removing the RTBC status since the merge request is still missing the changes that were discussed (#8) and added into the issue summary in #9

nitin_lama’s picture

Assigned: Unassigned » nitin_lama
nitin_lama’s picture

Assigned: nitin_lama » Unassigned
Status: Needs work » Needs review
FileSize
3.54 KB

Updated patch as per #9. Please review.

nitin_lama’s picture

Assigned: Unassigned » nitin_lama
Status: Needs review » Needs work

Working on it.

nitin_lama’s picture

Assigned: nitin_lama » Unassigned
Status: Needs work » Needs review
AaronMcHale’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Issue summary needs updating as we've now decided on which option to go with, currently it still shows the different possible options.

rkoller’s picture

Issue summary: View changes

Thanks @aaronmchale, good catch! I've updated the issue summary and adjusted the proposed resolution in 2) with a recommendation @benjifisher made in a follow-up conversation in the ux channel. He suggested to also remove the ..." whenever the module is enabled" part. Instead simply use "This role will be automatically granted all permissions" which is also inline with the wording used in the user help text.

and thanks @nitin_lama for adding the changes for the description on the roles settings page. unfortunately further tweaks to that particular string were discussed during the aforementioned follow-up discussion on slack. so a further tweak to the merge request would be needed.

rkoller’s picture

forgot to remove the "needs issue summary update" tag.

rkoller’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
23.48 KB
951 bytes

completely forgot about this issue. updated the second string to the second point of the proposed resolution. committed to the initially created merge request. i've also added a screenshot to the issue summary. the only detail i failed to accomplish is how to create an interdiff between two commits on gitlab. i've downloaded the plain diff via gitlab and attach it as a text file: https://git.drupalcode.org/issue/drupal-3293855/-/commit/a98b767f8e2c450...

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

Applying the MR 2485

Can confirm I'm seeing the text change on /admin/people/permissions and description change on /admin/people/role-settings. Matches directly to the issue summary.

larowlan’s picture

@rkoller fyi no need for an interdiff with gitlab, as there are individual commits

Adding issue credits

larowlan’s picture

Status: Reviewed & tested by the community » Fixed

Confirmed that the permission is the same for both pages.

Committed to 10.1.x, backported to 10.0.x and 9.5.x

  • larowlan committed 1d48add0 on 10.0.x
    Issue #3293855 by rkoller, rocketeerbkw, nitin_lama, Anchal_gupta,...

  • larowlan committed 9e5aef92 on 10.1.x
    Issue #3293855 by rkoller, rocketeerbkw, nitin_lama, Anchal_gupta,...

  • larowlan committed 040baa39 on 9.5.x
    Issue #3293855 by rkoller, rocketeerbkw, nitin_lama, Anchal_gupta,...
luenemann’s picture

Version: 10.0.x-dev » 9.5.x-dev

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.