Cash drawer
- openCashDrawer was a debugPrint. The drawer never opened.
- It cannot go through the PDF pipeline: a PDF is rendered by the platform
driver, which will not pass raw ESC/POS bytes to the device. So it goes over
a socket instead — nearly every network thermal printer listens on 9100 and
forwards whatever arrives straight to the print head, which makes the whole
protocol five bytes.
- Printer IP and port are configurable in Settings with a Test button that
saves and fires immediately, because a drawer that does not open is
indistinguishable from one that is not wired up.
- Every failure explains itself: unreachable, refused, or simply not
configured — which is the honest state for a USB printer, since there is no
raw path to one from Flutter.
- Now fires only on a cash tender. A card-only sale that pops the drawer is a
shrinkage risk, and it is the first thing a shop notices.
Back-office route
- Host, port, TLS and transport persist to the database; username, password
and API key go to the platform keystore (Keychain / Credential Manager /
Android Keystore). Writing credentials into SQLite would put them in the
same file as the bills, on a machine behind a shop counter.
- Loaded at startup. Previously the dialog wrote settings that were silently
ignored on the next launch, which reads exactly like they never saved — and
credentials retyped every morning end up on a sticky note instead.
- A saved route never overwrites the terminal's store or terminal id. Those
belong to the device, and re-pointing a till at a different broker must not
change who it is, or its bills and presence records stop lining up.
Tests: 168 -> 176. The drawer test stands up a real socket server and asserts
the exact bytes arrive. The config test asserts no credential appears anywhere
in the meta table while the non-secret settings do.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fdd90f28d9