Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAccess control
Device

List Access Roles

Review the access roles available to Harbor Demo Group or Harbor Soho from the User roles tab, with local search, scope filtering, pagination, refresh, and row actions controlled by permission and ownership.

In this article

The User roles tab gives organisation administrators and location managers a read-only starting point for checking which access roles are available in the current context before opening details or managing permissions.

The organisation list and location list deliberately show different ownership rules. Harbor Demo Group roles are managed from the organisation route, while Harbor Soho can show location-scope roles and inherited roles without making every visible role editable.

Before you start

  • Sign in with an account that has `permissions:view` or `permissions:manage` for the current organisation or location. A `system-admin` account can access both variants.
  • Select Harbor Demo Group before opening `organization/access?tab=roles`.
  • Select Harbor Soho before opening `location/access?tab=roles`.
  • Use the User roles tab inside Users and roles, or open the route directly with `tab=roles`.

Instructions

  1. 1.

    Open User Roles

    Open `organization/access?tab=roles` for Harbor Demo Group or `location/access?tab=roles` for Harbor Soho, then select User roles if the screen opens on another available tab.

  2. 2.

    Confirm The Context

    Use the organisation view for roles available at group level. Use the location view for roles available to Harbor Soho, including location-scope roles that may be inherited or owned by the current location.

  3. 3.

    Read The Table

    Review Name and Scope first. On wider screens, Description and Owner explain what the role is for and whether it belongs to Harbor Demo Group, Harbor Soho, or System.

  4. 4.

    Search And Filter

    Use Search by name or description and the scope selector to narrow the already loaded roles. The filter supports recognised scopes such as `organization`, `location`, and `system` when those options exist in the loaded list.

  5. 5.

    Page Or Refresh

    Use table pagination for longer lists and refresh when the server data needs to be reloaded. Search, scope, page, and page size stay as UI state and are not sent as listing payload fields.

  6. 6.

    Open A Role

    Select a row to open role details. Managers with `permissions:manage` can create roles and can edit or remove only roles owned by the current scope; view-only operators can inspect rows without write actions.

Validations and limits

  • Without `permissions:view` or `permissions:manage`, the User roles tab is not available; if no access tabs are available, the screen shows a no-permission state.
  • Missing organisation context returns a not-found state. The location variant also requires a selected location.
  • The organisation endpoint is `GET /api/app/{orgId}/roles`; the location endpoint is `GET /api/app/{orgId}/{locationId}/roles`. Neither listing endpoint receives a request body.
  • Organisation role listing excludes roles owned by a specific location. Location role listing returns location-scope roles relevant to the selected location context.
  • Rows are sorted by name before they reach the frontend, then search, scope filtering, and pagination are applied locally.
  • System-owned or inherited roles can be visible but remain read-only from this listing context.
  • An empty filtered table means no loaded role matches the current UI filters; this action does not create, edit, delete, or assign roles.

Expected result

The operator leaves the screen with a clear view of which access roles are available in the current organisation or location context, which roles are inherited or read-only, and which rows can be opened or managed safely.

Related articles