Antylogic
DemoApp login

399 operational guides

Docs sections
DocsTeam
Device

Delete an Approved Staff Vacation

Remove an approved staff vacation from Harbor Soho after a confirmation step. The action is permanent: the vacation disappears from the requests list and the underlying calendar event is deleted.

In this article

Use this guide when a manager needs to remove approved staff leave from the calendar, not when a pending request still needs approval or rejection.

The managed flow starts from all vacation requests with `pending_only=false`. Antylogic enables `Delete` only on approved rows, then sends `DELETE /api/app/{orgId}/{locationId}/calendar-events/{eventId}` after confirmation.

Before you start

  • You are signed in to Harbor Demo Group and Harbor Soho is the selected location.
  • Your role has `vacation:manage` for Harbor Soho. `vacation:view` can open the list but does not expose the managed row delete action.
  • An approved `staff_vacation` event exists in the selected date range. For captures, open `calendars/vacations/requests?pending_only=false`.
  • For the edit-form alternative, the documentation runtime must provide or discover an approved `staff_vacation` `eventId`.

Instructions

  1. 1.

    Open All Vacation Requests

    Open `calendars/vacations/requests?pending_only=false` for Harbor Soho. This view includes approved rows; the pending-only view is for review decisions and is not suitable for approved deletion.

  2. 2.

    Select an Approved Row

    Find a staff vacation with status `Accepted`. Use `Delete` only on an approved row; pending requests are resolved with approve or reject actions instead.

  3. 3.

    Confirm Deletion

    Choose `Delete`. Antylogic opens the `Delete event` confirmation modal with `This will remove Staff vacation permanently.` Cancelling or closing the modal leaves the vacation unchanged.

  4. 4.

    Verify The Result

    After confirmation, the app shows `Event deleted successfully.`, refreshes the vacation requests list and removes the deleted row. There is no undo after the deletion succeeds.

  5. 5.

    Use the Edit Form Alternative

    Open `calendars/edit/:eventId?kind=staff_vacation&returnRoute=LocationVacationsRequests` for an approved vacation. If it is not in `requested` state, the footer can show `Delete`; confirming uses the same permanent deletion and returns to the previous screen.

Validations and limits

  • The organisation and location context must be selected before the list or delete endpoint can operate.
  • The list query loads calendar events with `kinds=staff_vacation`; other calendar event kinds are outside this action.
  • The UI treats `accepted` and the historical value `approved` as approved states, and displays the approved status as `Accepted` in en-GB.
  • The managed row delete action requires `vacation:manage`; the backend has a narrower self-service exception for a user with `vacation:request` deleting only their own staff vacation, but that is not the documented manager flow.
  • The backend checks that the event exists, belongs to the current location and has a calendar kind with delete permissions. The backend does not check the vacation status, so the approved-only restriction is enforced by the managed UI.
  • The delete request has no body and should return `204 No Content`. On success, the client refreshes calendar event ranges and clears cached detail for the deleted `eventId`.
  • If the delete request fails, the app shows the resolved API error or `Couldn't delete the event.` and keeps the row until a successful refresh.

Expected result

The approved vacation is permanently removed from `calendar_events`. The staff record is not changed, and the refreshed vacation requests list no longer shows the deleted vacation.

Related articles