Antylogic
DemoApp login

399 operational guides

Docs sections
DocsAccess and users
Device

Respond to a Location Invitation

Accept or reject your own pending invitation to a location from Notifications. In the GB demo, Harbor Demo User responds to the Harbor Borough invitation under Harbor Demo Group; accepting activates the location membership and rejecting clears the pending invite when it has not already been accepted.

In this article

Location invitations are a personal access workflow. The signed-in user decides whether to join a location, and this action cannot update another user's membership.

The user works from Notifications: open the account menu, review the Harbor Borough invitation, then choose Accept or Reject. A successful response has no returned entity; the visible result comes from refreshed notifications, organisations and locations.

Accepting a location also ensures the required organisation membership is accepted when it is missing or still invited. Rejecting a still-pending location invite removes the invited membership instead of storing a rejected status.

Before you start

  • The invited user is signed in with a valid session or bearer token.
  • A pending `user_locations` membership exists for the signed-in user and target location with `status='invited'`.
  • For UI capture, Notifications contains a pending `user_notifications` item of type `location_invite` for Harbor Borough.
  • In the GB documentation runtime, use Harbor Demo User, Harbor Demo Group and Harbor Borough. Create the temporary invitation only in the capture runtime if it is missing, then clean it up after the run.

Instructions

  1. 1.

    Open Notifications

    From the user account area, open Notifications. The panel loads recent notifications and should show the Harbor Borough location invitation with View, Accept and Reject actions.

  2. 2.

    Check the Invitation Target

    Confirm that the invitation is for the expected location before responding. The View action may route to `/profile`, but it does not accept or reject the invitation.

  3. 3.

    Accept the Invitation

    Select Accept, then confirm the Accept invitation modal when the user should join Harbor Borough. The app sends `status='accepted'` to `PUT /api/app/me/locations/{locationId}` and then refreshes notifications, organisations and locations.

  4. 4.

    Reject the Invitation

    Select Reject, then confirm the Reject invitation modal when the user should not join the location. The app sends `status='rejected'`; for a still-pending invite, the pending location membership and invite notification are removed.

  5. 5.

    Handle Missing or Invalid Cases

    If the invitation is not visible, check the temporary fixture, the signed-in user, the target location and the pending notification. The route only accepts the response values `accepted` and `rejected`.

Validations and limits

  • The route is `PUT /api/app/me/locations/{locationId}`; other methods on that path are invalid for this action.
  • The request body must be decodable JSON with a `status` value.
  • `status` is trimmed, lowercased and limited to `accepted` or `rejected`.
  • The backend treats `{locationId}` as a location id, even where older documentation names the segment `{locationMembershipId}`.
  • The backend derives the organisation from the location and uses the signed-in user from context; the body cannot override `user_id`, `org_id` or `location_id`.
  • Accepting upserts `user_locations` to accepted and also accepts the organisation membership when it is missing or invited.
  • Rejecting a pending invite deletes the `user_locations` row. The database membership enum stores only `invited` and `accepted`, not `rejected`.
  • The API returns `204 No Content`; document the refreshed Notifications and location access, not a returned result object.
  • A faithful UI capture needs a controlled fixture because the current notification component responds to the organisation branch first when `notification.organization` is populated.

Expected result

The Harbor Borough invitation is consumed. Accepting activates the user’s location access, ensures the required organisation access and clears the invite notification; rejecting clears the pending invite and notification without storing a rejected membership.

Related articles