Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAccess and roles
Device

View own effective permissions

Understand how Antylogic resolves the signed-in user's effective permissions during session startup and uses them to show protected access-management areas such as Users and roles.

In this article

This article covers a background permission check, not a screen that operators open directly. Antylogic reads the signed-in user's own system permissions during authentication and keeps them as part of session state.

For Harbor Demo Group and Harbor Soho, the visible result is permission-gated navigation: Users and roles appears only when the current session and selected context include the required system, organisation or location permissions.

Before you start

  • The operator is signed in as Harbor Demo User with a valid Antylogic session.
  • Session loading has finished before checking protected menus or pages.
  • Harbor Demo Group and Harbor Soho are available as the selected organisation and location context.

Instructions

  1. 1.

    Start from a valid session

    Sign in as Harbor Demo User. During startup, Antylogic reads the user's own system permissions in the background through GET /api/app/me/permissions. There is no menu item that displays the raw permission response.

  2. 2.

    Keep the working context selected

    Work in Harbor Demo Group and Harbor Soho. Organisation and location permissions are loaded with the user's available organisations and locations, then combined with system permissions for navigation and action checks.

  3. 3.

    Open the protected access area

    Go to the organisation access area and confirm that Users and roles is available. The roles list is the operator-facing evidence that effective permission checks have resolved for the current session and context.

  4. 4.

    Avoid unsupported uses

    Do not use this action to edit permissions, inspect role assignments or query another user. It only supports the authenticated user's own session state.

Validations and limits

  • A missing or invalid session token prevents the check and the operator must sign in again.
  • GET /api/app/me/permissions returns system-scope permissions for the signed-in user, not the complete permission catalogue.
  • Organisation permissions come from GET /api/app/me/organizations, not from GET /api/app/me/permissions.
  • Location permissions come from GET /api/app/me/{orgId}/locations, not from GET /api/app/me/permissions.
  • An empty system-permissions response does not rule out organisation or location access.
  • The system-admin permission is treated by the app as allowing every permission and scope.
  • Do not document org_id or location_id as supported filters for GET /api/app/me/permissions.
  • PUT /api/app/me/permissions is unavailable for operator use, and the response does not include role names or role assignments.

Expected result

The signed-in session has the permission state needed for navigation and protected actions. Operators see the permitted access-management surfaces, while raw permissions and role internals remain hidden from the UI.

Related articles