The UI does not show the roles that the user has

Description

As a TRE user (Researcher, Workspace Owner, Airlock Manager or TRE Administrator)
I want the UI to show the roles that I have
So that I know why a function is not available, and I can give the correct data when I ask for help.

The UI knows the roles of the user, but it does not show them. It uses the roles only to select which elements to show:

• The core roles go into AppRolesContext. App.tsx sets them from the access token, which useAuthApiCall.ts#L90-L95 decodes.
• The workspace roles go into WorkspaceContext. WorkspaceProvider.tsx#L50-L78 gets them from the token and then sets them.
• These components read the roles field of the two contexts: SecuredByRole, LeftNav, RootLayout, ResourceCard, ResourceContextMenu, ResourceHistoryList, ResourceOperationsList, Airlock, WorkspaceProvider and WorkspaceUsers.
• Each of these components uses the roles for one of two functions. It selects which elements to show, or it selects the correct token scope for an API call. No component shows the roles to the user.

The user menu shows only the name of the user and the Logout command (UserMenu.tsx#L27).

This means that two different conditions look the same. SecuredByRole removes an element fully when the user does not have the role and the caller gives no error message. A Researcher who does not see the "Create new" button on the Workspaces page cannot find the cause. The cause can be the Researcher role, which is correct. The cause can also be a role assignment that is not yet in effect.

Only one part of the UI tells the user about the role of that user. WorkspaceProvider.tsx#L220-L225 shows a message to a TRE Admin who opens a workspace. This message is useful. SecuredByRole can also show an "Access Denied" message. But that message gives the necessary role. It does not give the roles that the user has.

The condition also increases the support work. To find the cause of "I cannot see X", you must ask the user to look in Entra ID. As an alternative, an administrator must look at the app role assignments of that user. But the token in the browser already has this data.

Tests are also more difficult. Each role sees a different page, because SecuredByRole removes the elements that the role does not permit. Thus you must test each change to a controlled function with each role.

This test procedure gives no clear indication of the current role. You change the app role assignment in Entra ID. Then you open the UI again. Then you must look at the buttons to decide if the new role is in effect. If the correct element is not there, there are two possible causes. The change has a defect, or the browser has a token that it received before the change to the role.

A role indicator makes this check direct:

1. Remove the user from the role.
2. Sign in again.
3. Make sure that the indicator shows the new set of roles.
4. Start the test of the change.

This gives the person who does the test a clear indication that the system is in the correct condition. This is most important for the roles for which a test account is difficult to get.

The indicator must use the same token claims that SecuredByRole uses. It must not read Entra ID directly. If it read Entra ID, the indicator and the UI could show different data. This difference is important, because it shows that the browser has an old token. The UI does not show this condition now.

Suggested solution

Show the roles that the client already has. A change to the API is not necessary, because the two sets of roles are already in the React contexts.

• Show the core roles (TREAdmin, TREUser) in the user menu. For example, show them as the secondary text of the Persona, or as a section of the menu.
• In a workspace, also show the roles that the user has in that workspace (WorkspaceOwner, WorkspaceResearcher, AirlockManager).
• Show an easy-to-read name for each role, not the value from the token. For example, show "TRE Administrator" for TREAdmin. A link to the User roles page is also useful.
• Show a message when the user has no roles in the current scope. For example, show "No roles assigned". This condition is the most difficult one to find now.

Acceptance criteria

• The user can always see the core TRE roles in the UI. The user does not have to open a workspace first.
• When the user opens a workspace, the user can also see the roles that the user has in that workspace.
• The UI shows an easy-to-read name for each role. It does not show the value from the token.
• When the user has no roles in the current scope, the UI shows a message. It does not show an empty area.
• When a TRE Admin opens a workspace in which that user has no workspace role, the UI shows this condition correctly. The message in WorkspaceProvider.tsx refers to this condition.
• The UI gets the roles from the same token claims that SecuredByRole uses. Thus the indicator and the available functions always agree.
• When you change an app role assignment in Entra ID and then sign in again, the indicator shows the new roles. Thus the person who does the test can make sure that the new role is in effect.
• Unit tests examine the new code. The tests must include the condition in which the user has no roles. Put the tests with UserMenu.test.tsx and SecuredByRole.test.tsx.
• Update the documentation if you add a new element to the UI.

Related issues

• #4376 asks for better descriptions of the role permissions in Entra ID and in the documentation. That issue tells the user what a role does. This issue tells the user which roles the user has.
• #3826 asks for more detailed role permissions. If the number of roles increases, a role indicator becomes more useful.
• #2861 (closed) added an error message for a user who does not have a necessary role. That message tells the user that a role is absent. This issue tells the user which roles the user has.
• #4049 (closed) added the Users tab of a workspace. That tab shows the roles of the other users. It does not show the roles of the user who signs in.
• #3809 (closed) added the TRE version and the deployment time to the UI. Footer.tsx shows this data. That change is similar, because it also adds status data to the UI.

Additional context

A token can contain these roles:

Scope	Value	Defined in
App registration for the core API	TREAdmin	devops/scripts/aad/create_api_application.sh
App registration for the core API	TREUser	devops/scripts/aad/create_api_application.sh
App registration for a workspace	WorkspaceOwner	templates/workspaces/base/terraform/aad/aad.tf
App registration for a workspace	WorkspaceResearcher	templates/workspaces/base/terraform/aad/aad.tf
App registration for a workspace	AirlockManager	templates/workspaces/base/terraform/aad/aad.tf

There is one more item, but it is not part of this request. The role TRERole.AirlockAutomation = "TREAirlockAutomation" is in api_app/auth/models.py#L10. The script create_api_application.sh does not create this role. No route and no test uses it. I can make a different issue for this role if it is not necessary.

Azure TRE release version: main (0.29.0)

Start with UserMenu.tsx, App.tsx, useAuthApiCall.ts, and WorkspaceProvider.tsx to trace the existing role claims and contexts, then run UserMenu.test.tsx and SecuredByRole.test.tsx. Done means the UI shows readable core and workspace roles, including an explicit no-roles state, with tests covering that condition and documentation updated if needed.