Offline mode

The app installs a small service worker that caches its own files and the four front-desk pages , Dashboard, Bookings, Rooms and Housekeeping. If you reload one of them with no network, the page shell still opens and fills itself from a local snapshot saved on the last successful load: the booking board window (±7 days plus everyone in-house), the room list, the housekeeping tasks and the dashboard tiles. The snapshot is refreshed every time the page loads or a live update arrives, so it is usually seconds old.

• Dashboard: shows the cached rooms, bookings and summary with a “saved at” time.
• Bookings: the pipeline board and drawers open from the cached window; queued check-ins and check-outs are already projected onto the cards.
• Rooms: the room grid with cached statuses; queued out-of-service changes appear immediately.
• Housekeeping: the task board and checklists from the cached task list.

Pages outside that set (Guests, Payments, POS, Reports, Settings…) are not cached. Their lists show “Could not load this page” until the connection returns. The API and the live-update socket are never cached, so nothing you see offline is ever older than the snapshot time.

When you press a button and the request cannot reach the API, the system checks whether that action is on the offline whitelist. Whitelisted actions are written to a local outbox in your browser (IndexedDB), the screen updates optimistically, and the toast says the action was queued rather than failed.

Everything else stays online-only: new bookings, new guests, new housekeeping tasks, work orders, payments, POS tickets, edits to dates or rooms, cancellations and no-shows. These mint new codes or move money and would duplicate on replay, so the button simply reports that you are offline. Take the details on paper and enter them once the Offline pill disappears.

The pill appears next to the quick-add button only when something needs saying:

• Offline (grey), the browser is offline or the live socket is down. Hover: “Working offline. Actions are queued locally”.
• Syncing (amber), you are back online and queued actions are being sent.
• Needs attention (red), at least one action could not be applied and is waiting for you.

The number on the pill is queued plus needs-attention rows. Click it to open the Offline activitydrawer, which has two lists:

1. 1
   Queued (n)

   Each row shows its label and “Captured 14:05”. Sync now forces a replay; the toast answers “All queued actions sent” or “Still offline. Will retry automatically”.
2. 2
   Needs attention (n)

   Rows the server refused, with the server's message and the context (guest, room). Resolve them manually, for example re-room the guest from Bookings, then press Dismiss.

Replay is triggered automatically when the browser comes back online, when the tab becomes visible again, when the live socket reconnects, and three seconds after the app starts. You rarely need Sync now.

The outbox groups rows by record, booking:…, room:…, hk:…: and replays each group strictly in order, so a queued check-out can never run before its check-in. Groups are independent: a problem on one booking does not hold up the room changes. Every flush starts by refreshing your session so the replay runs with a fresh cookie, and ends by reconnecting the live socket so every open screen refetches.

• Success: the row is removed.
• Converged: the server answered 409 but a quick check shows the record is already where you wanted it (the booking is checkedin, the task is already in that column, the room is already out of service). Another desk did it first. The row is dropped silently; nothing to do.
• Genuine conflict: a 409 whose state does not match, typically Room is already booked for those dates or Room 204 is unavailable. The row moves to Needs attention with the server's message. Open the booking, pick another room and check in again, then dismiss the row.
• Other refusals: 400, 403 (your role changed), 404 (the record was deleted) or a booking that was cancelled meanwhile. Also parked under Needs attention with the message; they can never succeed as queued.
• Network failure: the row stays queued and the whole flush stops until the next trigger.
• 401: the session could not be refreshed. The queue pauses and you are taken to sign-in; the rows are kept and replay after you sign in again.

Queued check-ins and check-outs carry an occurredAt stamp taken the moment you pressed the button. On replay the server uses it for the booking's check-in/out time and for the arrival-day rule, so the folio and the night audit reflect when the guest actually arrived, not when the network came back.

• The stamp must be within the last 48 hours and never in the future; older rows are refused with occurredAt must be within the last 48 hours and land in Needs attention.
• The booking's status history and the audit log keep who did it and when it was captured.
• Housekeeping and room changes do not carry a stamp; they take the time they are applied.

1. 1
   Desktop (Chrome or Edge)

   Open the app, then choose Install app from the address-bar menu. It appears as “HMS” in your apps and launches on the Dashboard.
2. 2
   Phone or tablet

   Use Add to Home Screen from the browser's share or menu. iPad Safari is supported; the queue works there too.
3. 3
   Updates

   When a new build is deployed, a bar at the bottom says “A new version is available.” Press Update to reload onto it, or Later to finish what you are doing first.