• v0.8.0 e5916d522a

    Let an on-call day be handed to somebody else
    Release / build (amd64, darwin) (push) Has been skipped
    Release / build (arm64, darwin) (push) Has been skipped
    Release / docker (push) Has been skipped
    Release / release (push) Has been skipped
    Release / test (push) Failing after 6s
    Release / build (amd64, linux) (push) Has been skipped
    Release / build (arm64, linux) (push) Has been skipped
    Release / chart (push) Has been skipped

    niklas released this 2026-08-07 12:04:11 +00:00 | 102 commits to main since this release

    A date is held by exactly one person and POST /api/schedule plain-inserts,
    so any date that was already taken came back 409. That made reassignment
    impossible through the API: the only route was to delete the entry first,
    and for a week that meant seven separate deletions. Worse, the reject is
    all-or-nothing across the request, so assigning a week where a single day
    happened to be taken failed entirely and placed none of the other six.

    The refusal itself is worth keeping. Moving a shift off the person
    expecting to be paged for it should not be something a plain call does by
    accident, so the fix is to make it possible to ask for rather than to
    remove the guard: "replace": true takes the dates anyway, and the flag
    defaults to off so every existing caller behaves exactly as before.

    The delete and the insert share the transaction that was already there.
    That matters more than the flag does — a week of free and taken days now
    lands as a unit, and a failure part way through leaves the rota as it was
    instead of with a shift deleted and nothing put back. A rota with a hole
    in it is worse than a rota that refused to change.

    One consequence worth naming: under replace a date repeated inside one
    request is idempotent rather than a conflict, because the second pass
    clears what the first wrote.

    Downloads