User: Display field for role not working (always set to ID)

[biancajs]

• Node.js version: v16.20.0
• NPM version: 8.19.4
• Strapi version: v4.12.1
• Database: mysql
• Operating system: macOS
• Is your project Javascript or Typescript: js

Describe the bug

There might be a minor bug: when creating a new user the related role fields only shows the IDs as a dropdown list (the display field is explicitly set to "name"). That's a bit confusing for content editors.

Steps to reproduce the behavior

1. Go to: Content Manger -> User
2. Click on: Create new Entry (or open an existing one)
3. Instead of the name ("authenticated", "public", etc.) the ID is referenced
4. (Check if: Content Type Builder -> User -> Configure the view -> Role: is set to "name")

Expected behavior

Instead of the ID the name of the role should be shown ("authenticated" etc.)

Screenshots

Code snippets

If applicable, add code samples to help explain your problem.

Additional context

Add any other context about the problem here.

[bglidwell]

Actually unable to change roles for existing users as well. Getting internal server error. Downgrading version restores functionality, so it seems to be with this update.

023-08-03T17:49:50.034819+00:00 app[web.1]: [2023-08-03 17:49:50.034] error: UPDATE "strapiv4"."up_users_role_links" as a
2023-08-03T17:49:50.034821+00:00 app[web.1]: SET "user_order" = b.inv_order
2023-08-03T17:49:50.034821+00:00 app[web.1]: FROM ( select "id", row_number() over (partition by "role_id" order by "user_order") as inv_order from "up_users_role_links" where "role_id" in ($1) ) AS b
2023-08-03T17:49:50.034822+00:00 app[web.1]: WHERE b.id = a.id - relation "up_users_role_links" does not exist
2023-08-03T17:49:50.034826+00:00 app[web.1]: error: UPDATE "strapiv4"."up_users_role_links" as a
2023-08-03T17:49:50.034826+00:00 app[web.1]: SET "user_order" = b.inv_order
2023-08-03T17:49:50.034827+00:00 app[web.1]: FROM ( select "id", row_number() over (partition by "role_id" order by "user_order") as inv_order from "up_users_role_links" where "role_id" in ($1) ) AS b
2023-08-03T17:49:50.034827+00:00 app[web.1]: WHERE b.id = a.id - relation "up_users_role_links" does not exist

[derrickmehaffy]

I believe this was related to a security fix that we implemented recently where it will block certain fields if they don't have the permission to view them but that shouldn't impact some of the admin content-types 🤔

Thoughts @alexandrebodin / @Convly / @innerdvations ?

[vagelisp]

Hello all,
I have the same issue with an admin::user relation field that could be related to this.

"admin_users": {
      "type": "relation",
      "relation": "oneToMany",
      "target": "admin::user"
    }

It will always display the ID no matter what I set it to display.

That's on a fresh installation which is pretty light as I am just working on a plugin ( tested with and without and makes no difference )

• Node.js version: 18.16.0
• NPM version: 9.7.2
• Strapi version: 4.12.1
• Database: SQLite
• Operating system: MacOS
• Is your project Javascript or Typescript: JS

[McSego1990]

same here to :)

[delta-source]

same issue for me

[innerdvations]

I believe this was related to a security fix that we implemented recently where it will block certain fields if they don't have the permission to view them but that shouldn't impact some of the admin content-types 🤔

Thoughts @alexandrebodin / @Convly / @innerdvations ?

Yeah, that sounds right, it was just changed so that if a user doesn't have permissions on a relation they can only select the id field.

I'll look into this issue and see what we can do.

However, I'm not seeing the database error @bglidwell saw, I seem to be able to update role with no issue. Can anyone post steps to reproduce that?

[innerdvations]

@derrickmehaffy I've confirmed this is actually a bug with the permissions check, specifically relating to u&p it seems, so it's not an issue with users needing to set additional permissions

[bglidwell]

If it helps, the database error only seems to be happening on Postgres. Our local with SQLite is fine. Will look into it more this week to get a better root cause.