Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAccess and users
Device

List location users

Review the users linked to Harbor Soho with search, server-side pagination, access status, contact details and the employee role when the user is connected to active staff.

In this article

Use this guide when an operator needs to confirm who is linked to one location before service. The list is scoped to Harbor Soho and keeps invitation, creation, editing, removal and role assignment in separate management actions.

The screen is visible from the location Users and roles area, but the list request still depends on the backend `users:view` permission for the selected location.

Before you start

  • Sign in with a valid Antylogic session for `/api/app/` routes.
  • Select Harbor Demo Group as the organisation and Harbor Soho as the active location.
  • Use an owner, system-admin or role that includes `users:view` for the location. `users:manage` may expose management controls, but it does not replace `users:view` for the list request.
  • Open `location/access` with the Users tab selected, or use `antylogic://${ORG_ID}/${LOCATION_ID}/location/access?tab=users` for capture runs.

Instructions

  1. 1.

    Open Users and roles

    From the active Harbor Soho context, open the location access area and select Users. The page should show Users and roles, the location-level description, and the Users tab when the operator can view users.

  2. 2.

    Read the Location users table

    Use the Location users table to review Name, Status, Email, Phone and Employee role. Missing contact or role values appear as a dash, and the displayed name falls back from full name to email and then to the user id.

  3. 3.

    Search users

    Type in Search by name or email to narrow the list. In the GB demo, Olivia is the documented search example; the app trims the query, updates `users_query` in the route and returns to page 1.

  4. 4.

    Move through pages

    Use Previous and Next to move through server-side pages. The default UI state is page 1 with page size 10, and the screen adjusts the page if filtering leaves the current page outside the available total.

  5. 5.

    Refresh or inspect a row

    Use refresh to reload the list. Selecting a row opens the location user detail for that user; operators without `users:manage` see a view-only row action, while management actions remain outside this read-only listing guide.

  6. 6.

    Handle access, loading and errors

    During initial load the screen shows the users and roles loading state. If the request fails it shows the user and role load error, and if the operator has no available tabs it shows the location no-access message instead of the table.

Validations and limits

  • `/api/app/` routes require authentication before the users handler runs.
  • The location users query is enabled only when organisation id, location id, location scope and user-view access are available.
  • `GET /api/app/{orgId}/{locationId}/users` requires `users:view` and returns only memberships for the selected location.
  • The backend searches `full_name`, `email` and `phone_e164` and returns `items`, `page`, `page_size` and `total`.
  • The visible UI exposes text search and pagination only. `status` and `without_staff` are API filters, not controls on this screen.
  • Status can appear as Active, Invited, Inactive, No permissions, Owner, Employee or Device depending on membership, user activity and internal access context.
  • Employee role is informational here and comes from active staff linked to the same user and location.

Expected result

The operator has a scoped, searchable and paginated view of who is linked to Harbor Soho, with enough status, contact and employee-role context to review access without changing memberships from this listing action.

Related articles