- First commit to issue fork.
- @vidorado opened merge request.
- 🇺🇸United States smustgrave
Believe this will need an upgrade path + update test. Currently with this change think you currently have access to you would have it ripped away. Believe proper approach would be that things shouldn't change for existing users but can be configured to take away after the fact by the site admin.
- 🇪🇸Spain vidorado Logroño (La Rioja)
@smustgrave I don’t see how users could suddenly lose their access. The only users who had view+edit access to roles in user edit forms were those with the "Administer permissions" permission, and that remains unchanged. As far as I understand, the only addition in this change is a read-only view of one's own roles for users with "View own account details" permission.
Regarding REST APIs, we’ve only added an
AccessResult::allowed()
when the user has "View own account details", while keepingAccessResult::neutral()
otherwise, which aligns with the previous behavior.Could you clarify where exactly you see a potential permission loss?
Thanks!
- 🇺🇸United States smustgrave
You're adding a new permission that no one will have
- 🇪🇸Spain vidorado Logroño (La Rioja)
So, are you suggesting that the "View own account details" permission should be granted to authenticated users by default? That could make sense, but it would also mean that users would suddenly see their roles appearing in their own user edit forms.
If that’s the intended behavior, an upgrade path should be implemented. However, I’m not entirely sure if that would be the best approach. What do you think?
- 🇺🇸United States smustgrave
If we don't do upgrade paths then think we least need a CR, probably need that anyway. CR should include the new permission, it's purpose, and maybe when it should be used (as an example)
- Status changed to Needs review
20 days ago 10:15am 4 April 2025 The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.
- 🇮🇳India prashant.c Dharamshala
prashant.c → made their first commit to this issue’s fork.
- 🇮🇳India prashant.c Dharamshala
- Rebased the merge request and resolved minor PHP CodeSniffer issues.
- The current permission name, "View own account details", is too generic for its actual purpose.
- This permission specifically controls access to the roles section on the user account edit page.
- Even without this permission, users can still view and edit their own account details.
- Ideally, if we retain the current permission name, it should only apply to the "/user/[uid]" page, and not to "/user/[uid]/edit".
- In my opinion, for better clarity and purpose alignment, a more appropriate permission name would be something like "View user roles" or "View own roles".