'roles' field on User entity is never accessible: make accessible to admin users

Created on 7 February 2019, about 6 years ago
Updated 2 February 2025, 3 months ago

Hello,

I am using graphql with Drupal, but I think this issue might be a generic drupal core issue so opening it up in here. Currently when accessing the user roles via an endpoint (graphql, json api or REST I think ) the user's roles is always set to access denied and return empty if the user is not an administrator.

It might be a similar situation to https://www.drupal.org/project/drupal/issues/3026264 (?). With some pointers I would be able to get a patch started here and kick off the conversation.

I guess it would be ok to allow users to access their own roles by default, maybe accessing other user's roles could already be classified as an access violation of some sort.

Looking forward for some feedback! thanks! ) Cheers

Feature request
Status

Needs work

Version

11.0 🔥

Component

user.module

Created by

🇵🇹Portugal joaogarin

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • 🇪🇸Spain vidorado Logroño (La Rioja)
  • @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 keeping AccessResult::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
  • 🇪🇸Spain vidorado Logroño (La Rioja)

    I've created a CR :)

  • 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
  • 🇮🇳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".
Production build 0.71.5 2024