Conflict detection
What it is
Section titled “What it is”Conflict detection is the rule that prevents two confirmed bookings from overlapping on the same asset. It is enforced on the server, not just by the app. That means it still holds when two members try to book the same slot at the same time from two different devices, and when a booking is created while offline and syncs later.
Who can use it
Section titled “Who can use it”Conflict detection applies to everyone. There is no bypass for admins: the server applies the rule on every confirmed booking, regardless of who created it.
Where to find it
Section titled “Where to find it”You never see conflict detection directly. You encounter it:
- When you try to create a confirmed booking that overlaps an existing confirmed booking, the create dialog returns an error explaining the conflict.
- When an offline booking created on a phone reaches the server and is rejected because another confirmed booking landed first. The app removes the rejected booking from your device automatically and sends you a notification that the slot was taken; to rebook, create a new booking for a free time.
The rule
Section titled “The rule”There are no user-facing fields. The underlying rule is:
For any asset, no two bookings with status confirmed may have overlapping time ranges.
The check is run on the server every time a booking is inserted, updated, or promoted to confirmed, so there is no way to slip past it from any client.
Behaviour rules
Section titled “Behaviour rules”- Confirmed-only. The check applies only to bookings in confirmed status. Tentative and pending bookings can overlap freely, with each other and with confirmed bookings. This is the whole point of the tentative model (see Tentative bookings).
- Same-asset only. Two confirmed bookings on different assets can happily overlap. The asset is the thing being reserved.
- Inclusive of start, exclusive of end. A booking from 09:00 to 10:00 does not conflict with one starting at 10:00.
- Cross-status transitions. When a pending booking is approved or a tentative is confirmed, the check runs at that point. If another booking has slipped in and taken the slot, the promotion fails and the booking stays in its previous state.
- Offline safety. If a member creates a booking offline and another member takes the same slot online before the first device reconnects, the offline booking is rejected on sync. Last-write-wins does not apply to booking conflicts. The server rejects the later write, the rejected booking is removed from the author’s device, and the author is notified that the slot was taken.