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.
At the same time the description of the select box on the role settings page is incorrect and is creating a false expectation.
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.
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.
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.
Comment | File | Size | Author |
---|---|---|---|
#22 | interdiff_5-22.txt | 951 bytes | rkoller |
#22 | all_permissions.jpg | 23.48 KB | rkoller |
#13 | updating-outdated-help-text-3293855-13.patch | 3.54 KB | nitin_lama |
#10 | after.png | 462.76 KB | Anchal_gupta |
#10 | before.png | 158.41 KB | Anchal_gupta |
Issue fork drupal-3293855
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:
Comments
Comment #2
rkollerComment #3
rocketeerbkw CreditAttribution: rocketeerbkw as a volunteer commentedThe Austin Drupal Dojo is working on this issue tonight.
Comment #5
rocketeerbkw CreditAttribution: rocketeerbkw as a volunteer commentedWe 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.
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
Comment #6
cutehair CreditAttribution: cutehair as a volunteer commentedOur Dojo worked together to remedy this bug.
Comment #7
AaronMcHaleThis 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.
Comment #8
rkollerWe'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 sentenceChanging 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.
Comment #9
rkollerComment #10
Anchal_gupta CreditAttribution: Anchal_gupta at Srijan | A Material+ Company for Drupal India Association commentedApplied MR #4 on 10.0.x. The help text has been updated after applying this MR #2485.
Comment #11
rkollerForgot 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
Comment #12
nitin_lamaComment #13
nitin_lamaUpdated patch as per #9. Please review.
Comment #15
nitin_lamaWorking on it.
Comment #18
nitin_lamaComment #19
AaronMcHaleIssue summary needs updating as we've now decided on which option to go with, currently it still shows the different possible options.
Comment #20
rkollerThanks @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.
Comment #21
rkollerforgot to remove the "needs issue summary update" tag.
Comment #22
rkollercompletely 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...
Comment #23
smustgrave CreditAttribution: smustgrave at Mobomo commentedApplying 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.
Comment #24
larowlan@rkoller fyi no need for an interdiff with gitlab, as there are individual commits
Adding issue credits
Comment #25
larowlanConfirmed that the permission is the same for both pages.
Committed to 10.1.x, backported to 10.0.x and 9.5.x
Comment #29
luenemann