How to view role details

In this article

Before you start

• Be signed in with the Harbor Demo Group application context loaded.
• For organisation role detail, `ORG_ID` must be selected and the role must be visible from `GET /api/app/{orgId}/roles/{roleId}`.
• For Harbor Soho location role detail, `ORG_ID` and `LOCATION_ID` must be selected and the role must be visible from `GET /api/app/{orgId}/{locationId}/roles/{roleId}`.
• Have effective permission-view access in the selected context. The UI can open with `permissions:view` or `permissions:manage`, while the backend detail requests require `PermissionsView`.
• Use a concrete role ID. The current GB runtime has `ORG_ID` and `LOCATION_ID`, but it does not include `BOOTSTRAP_MANAGE_PERMISSIONS_ORG_ROLE_ID`, `BOOTSTRAP_MANAGE_PERMISSIONS_LOCATION_ROLE_ID` or `ACCESS_ROLES_READONLY_INHERITED_ROLE_ID`.

Instructions

1. 1.

   Open User roles

   Start from `organization/access?tab=roles` for Harbor Demo Group or `location/access?tab=roles` for Harbor Soho. From a user detail page, use the assigned roles table and open the role action from there.

2. 2.

   Select the role to inspect

   Open a row or use the available row action. Editable and non-editable rows navigate to the same Role details surface, but the selected role ID must resolve in the current organisation or location endpoint.

3. 3.

   Review Name, Description and Scope

   On Role details, check the role fields. Scope is informational for an existing role in this view-detail action; changing scope, saving or deleting belongs to separate role-management actions.

4. 4.

   Inspect assigned permissions

   Use the Permissions section to review permission code, description and type information. The selected count summarises assigned permissions, and the search field filters by code or description within the role's valid scope.

5. 5.

   Recognise read-only detail

   If the operator only has view access, or the role is inherited rather than owned by the current scope, the page is read-only. Document the absence of Save and Delete, and treat permission assignment as outside this action.

6. 6.

   Return to the previous context

   Use Back to roles or the stable Cancel return control to go back to the roles tab. When the detail was opened from a user detail page, the return path preserves that parent user context.

Validations and limits

• The selected organisation must be present; for location detail, the selected location must also be present.
• The role ID must resolve in the current endpoint before the detail can show the role fields and assigned permission IDs.
• The detail and permission requests are GET-only for this action and do not mutate `roles`, `permissions` or `role_permissions`.
• Organisation detail does not expose roles owned by a specific location; location detail opens only location-scope roles visible to Harbor Soho.
• The permission catalogue is filtered to permissions valid for the role scope, and search is applied to permission code and description.
• Read-only inherited role documentation should rely on the absence of Save and Delete; do not claim every checkbox is visually disabled because that visual detail was not fully verified.
• Do not deep link to a role detail route without a concrete `roleId`, because the shared form can enter create mode when the ID is missing.

Expected result

The operator can verify what an organisation or Harbor Soho access role contains, understand whether it is owned or inherited, and leave the page without changing roles or permission assignments.