hotel-manage-stack/tablet-checkin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tablet-checkin/backend/extension-src
History
jtricerolph 4aeca15281 Extension: surface a disconnected-tablet warning instead of silent success 
A push can succeed server-side (session created) with nowhere to actually
deliver to — the backend's pushNavigate() already distinguishes this via a
delivered:false return (see device-stream.js), but nothing in the extension
read it: every surface just said "Sent" regardless. Confirmed live on the
dev stack 2026-10-01 — the registered dev tablet hadn't heartbeated in a
month, so a push looked successful but nothing happened. Now every send
path (injected buttons' fast path + manual picker, popup's fast path +
manual picker) shows an amber "tablet isn't connected right now" warning
when delivered is false.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-01 12:02:56 +00:00
..
icons Extension: Send to Tablet on the checkin page, popup auto-push, reset, new icon 2026-10-01 11:37:44 +00:00
options Extension: fix duplicate checkin banner and silently-unsaved default tablet 2026-10-01 11:48:53 +00:00
popup Extension: surface a disconnected-tablet warning instead of silent success 2026-10-01 12:02:56 +00:00
background.js Extension: surface a disconnected-tablet warning instead of silent success 2026-10-01 12:02:56 +00:00
content-script.js Extension: surface a disconnected-tablet warning instead of silent success 2026-10-01 12:02:56 +00:00
manifest.json Extension: Send to Tablet on the checkin page, popup auto-push, reset, new icon 2026-10-01 11:37:44 +00:00
newbook-auth.js Fix NewBook write mechanism, bundle push extension, remove vestigial hotel_id 2026-09-01 18:11:35 +00:00
README.md Fix NewBook write mechanism, bundle push extension, remove vestigial hotel_id 2026-09-01 18:11:35 +00:00

README.md

Send to Check-In Tablet

Standalone Chrome extension — deliberately separate from chrome-newbook-assistant (see project_checkin memory's "Standalone push extension" decision). Its one job: detect a NewBook booking page and push that booking to a physical check-in tablet running the tablet-checkin app.

How it works

  • Detection: a background service worker watches for NewBook booking pages (bookings_view/<id>, bookings_edit/<id>, bookings_checkin/<id> — confirmed real URLs, 2026-09-01) and shows a badge on the toolbar icon when one's open. The SPA-navigation handling (webNavigation.onHistoryStateUpdated) is lifted directly from chrome-newbook-assistant/background.js (~/laptop-archive) — already proven against real NewBook navigation, not guessed here.
  • Popup: click the toolbar icon → shows the detected booking number, a device picker (busy tablets shown disabled), and a "Send to Check-In Tablet" button.
  • Row-injected button: on NewBook's "due for arrival" list (bookings_lists_checkin), a content script adds a "Send to Tablet" button under each row's own Check In button, with an inline device picker. Row detection and the booking-ID extraction are built from a real sample row the user provided (2026-09-01, see project_checkin memory) — deliberately doesn't rely on any id attribute from NewBook's own markup, since its Check In button reuses the same id across every row (generic_button_1), only class/attribute selectors scoped per row. A MutationObserver re-scans for new rows since this page refreshes its table via AJAX without a full reload.
  • NewBook login indicator: the popup shows whether the browser looks logged into NewBook (cookie-based check, also lifted from chrome-newbook-assistant's AuthManager.checkNewBookAuth). This is a UX signal only — it does not authorize anything. The actual push call authenticates with a terminal API key (below), not the NewBook cookie.
  • Auth: the push call itself is authorized by a terminal API key, generated from tablet-checkin's own Terminals admin page (admin capability) and pasted into this extension's Settings page. This mirrors the same trust model already used for the tablets themselves — hotel-owned hardware gets a device-level credential, not a per-user login. See project_checkin memory's "Extension auth" section for the full reasoning.

Setup

  1. Deploy tablet-checkin and note its base URL.
  2. In tablet-checkin, go to Terminals (requires admin capability) → create a terminal (e.g. "Reception PC 1") → copy the key shown (only shown once).
  3. Load this extension unpacked: chrome://extensions → Developer mode → Load unpacked → select this folder.
  4. Click the extension icon → Open Settings (or right-click the icon → Options) → enter the tablet-checkin base URL and the terminal key → Save → Test connection.

Known TODOs before this is production-ready

  • Row-detection selectors on bookings_lists_checkin are built from a single sample row (2026-09-01) — robust in principle (class/attribute-based, not relying on NewBook's non-unique ids), but only actually tested against one row's markup so far. Worth confirming against a live page with multiple/varied rows (different booking statuses, group bookings, etc.) before relying on it daily.
  • host_permissions in manifest.json only covers the NewBook domains (needed for the cookie-detection API) — tablet-checkin's own backend host isn't declared there since its production URL isn't fixed yet. Cross-origin fetch() calls from the popup/options pages generally work regardless, but add the real host once known if CORS issues show up.
  • Icons are placeholder-generated (simple crimson square + gold arrow, matching tablet-checkin's theme color) — replace if a proper design is wanted.
  • Not yet published anywhere (Chrome Web Store or otherwise) — currently load-unpacked only, meaning it needs manually installing on every reception PC. tablet-checkin's own Settings page has a download link (a bundled copy of this source, zipped on request) as of 2026-09-01 — keep backend/extension-src/ in that repo in sync with this folder, they are not currently the same copy.