Skip to content

Show a code on the till so a phone can be pointed at this shop - #502

Merged
sridharkalaibala merged 2 commits into
developfrom
pair-qr
Sep 11, 2026
Merged

sridharkalaibala merged 2 commits into
developfrom
pair-qr

Conversation

@sridharkalaibala

Copy link
Copy Markdown
Contributor

Setting up a staff handset meant typing an address, and the person holding the phone is the one who does not know it. The owner knows the shop code; a waiter five minutes into their first shift does not, and had no way to find out.

So the till shows a code and the phone reads it. GET /pair renders a printable page with a QR for every address a phone could actually reach this machine on. Captain already scans it.

Which address goes on the code

That is the whole substance, and getting it wrong is invisible here: the page renders a perfectly good QR for an address the phone cannot reach, and it surfaces minutes later on somebody else's handset as "cannot find the shop".

  • A till opened locally sees localhost:5555 in its own address bar, and a phone pointed at localhost is pointed at itself. So addresses come from the network interfaces, not from the request.
  • Wi-Fi first, because a till is often wired and wireless and the phone is on the wireless one.
  • A shop reached at a public address gets that instead, since it keeps working away from the shop.
  • A machine with no network says so rather than inventing an address.

The decision lives in api/src/utils/pairing.js with no dependencies, so it is testable without express, qrcode or a running server. 8 tests cover it.

Public on purpose

Declared in public-routes.test.js with a reason, which is what that test is for. The code carries an address, not a credential - the same thing the till's own address bar shows anybody standing at it. Requiring a login would mean a handset cannot be paired until somebody signs in on the till, which is backwards: pairing is what happens before anyone can.

Notes

  • Uses the qrcode package the API already depends on. No new dependencies.
  • docs/API.md, docs/openapi.json and the README endpoint count regenerated, as the docs gate requires.
  • Full suite at parity with develop: same failures before and after, plus 8 new passing tests.

Setting up a staff handset meant typing an address, and the person holding
the phone is the one who does not know it. The owner knows the shop code; a
waiter five minutes into their first shift does not, and had no way to find
out.

So the till shows a code and the phone reads it. GET /pair renders a
printable page with a QR for every address a phone could actually reach
this machine on. The Captain app already scans it.

Which address goes on the code is the whole substance, and getting it wrong
is invisible here: the page renders a perfectly good QR for an address the
phone cannot reach, and it surfaces minutes later on somebody else's
handset as "cannot find the shop". A till opened locally sees
localhost:5555 in its own address bar, and a phone pointed at localhost is
pointed at itself - so the addresses come from the network interfaces, not
from the request, Wi-Fi first because a till is often wired and wireless
and the phone is on the wireless one. A shop reached at a public address
gets that instead, because it keeps working away from the shop.

The decision lives in api/src/utils/pairing.js with no dependencies, so it
is testable without express, qrcode or a running server.

Public on purpose, and declared as such in public-routes.test.js: the code
carries an ADDRESS, not a credential - the same thing the till's own
address bar shows anybody standing at it. Requiring a login would mean a
handset cannot be paired until somebody signs in on the till, which is
backwards, since pairing is what happens before anyone can.

Uses the qrcode package the API already depends on. No new dependencies.
The CI lint job runs prettier --check over api/src. ESLint was already
clean; this is whitespace only.
@sridharkalaibala
sridharkalaibala merged commit 44a78a2 into develop Sep 11, 2026
8 checks passed
@github-actions github-actions Bot added the ready for QA Merged to develop and live on develop.posnic.io - anyone can test it label Sep 11, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready for QA Merged to develop and live on develop.posnic.io - anyone can test it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants