Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAccess and users
Device

How to remove an internal location user

Remove a temporary internal Harbor Soho user whose internal credentials belong to the selected location, without treating external location members as full identity deletes.

In this article

Use this guide when Harbor Soho needs to retire a temporary internal login from location access. The operator verifies the internal user edit form, opens the remove confirmation, and confirms the deletion from the selected location context.

This is not a generic delete for every location user. Antylogic only deletes the full internal identity when the loaded detail has internal_access and the internal_credentials namespace matches Harbor Soho; external users follow the membership removal path instead.

Before you start

  • You are signed in to Antylogic with Harbor Demo Group and Harbor Soho selected.
  • You can view location users, and you have users:manage to complete the removal; users:view alone can open the detail but does not show the destructive action.
  • The target route location/access/users/:userId points to a user with primary_auth_provider === "internal-credentials".
  • The loaded user detail includes internal_access for the current Harbor Soho location.
  • For captures, use only a temporary internal Harbor Soho user created in the documentation runtime, never Harbor Demo User, an organisation owner, Olivia Hart or another permanent demo login.

Instructions

  1. 1.

    Open location users

    Open location/access under Harbor Soho and use the users list to select the temporary internal user that should be removed.

  2. 2.

    Open the internal user detail

    Open location/access/users/:userId. When the user detail returns internal_access, Antylogic renders the internal edit form instead of the standard location membership detail.

  3. 3.

    Check the internal edit form

    Confirm that the form is in edit mode and shows the internal access fields, profile fields, roles and the destructive Eliminar action. The implemented form still includes labels such as Tipo de acceso, User ID, Contrasena, Telefono and Guardar cambios.

  4. 4.

    Open the confirmation modal

    Select Eliminar. The only visible confirmation step is the modal titled Remove user, with text explaining that the named user will be removed from this location.

  5. 5.

    Confirm the removal

    Select Remove in the modal. The app sends DELETE /api/app/{orgId}/{locationId}/users/{userId} with no request body; the user id is supplied only in the route path.

  6. 6.

    Check the refreshed list

    After a successful 204 No Content response, Antylogic invalidates the location user queries, returns to location/access and the temporary internal user should no longer be listed.

Validations and limits

  • The destructive action is not shown without users:manage, a present userId and internal_access for the current location.
  • If the page shows the standard non-internal user detail, stop; this guide does not apply to that user.
  • The backend validates orgId, locationId and userId, confirms that the location belongs to the organisation, and blocks removal of the organisation owner.
  • A full internal identity delete runs only when internal_credentials belongs to an access_namespaces row with scope_type location and the same locationId.
  • If the namespace does not match Harbor Soho, the endpoint follows the general location membership removal path instead of deleting the complete user identity.
  • If authCleanup fails, the transaction aborts before repo.DeleteUser runs.
  • The DELETE request has no body or payload fields.

Expected result

The temporary internal Harbor Soho identity is removed from the selected location, the location users list is refreshed, and permanent demo accounts remain outside the documented destructive flow.

Related articles