A setting that only half the screens obeyed
We added a switch to turn the add-on row off. It turned it off on the guest menu and left the register still offering them — because two screens read the same setting from two different places.
Suggestions in HelchPOS now appear in three places, and each can be set separately: the add-on row, the rail in the basket, and the blocks inside an item's own sheet. Each follows the venue's setting by default, or is given one of its own — including off.
Which is a good feature, and for one release it was a lie.
Same row, two readers
The one-tap add-on row appears in two places: above the guest menu, and above the totals on the register. Same feature, same list, same purpose. But the guest menu and the register load their menus through different routes, and only one of them had been taught about the new setting. The other read the venue's mode directly, as it always had.
So an operator could turn the add-on row off, watch it vanish from the guest menu, and have the register carry on offering them at the counter all night.
A setting that does something on some screens is worse than one that does nothing on all of them, because the operator has evidence it worked.
Where a setting should be worked out
The fix was not to teach the register the rule as well. Two copies of a rule is two rules, and they drift. Every screen now gets its list already resolved by the server — already ranked by whatever that surface is set to, already empty when it is off — so no screen has to work out an override for itself, and none of them can disagree about it.
The item sheet needed no change at all as a result. It reads what it is handed, and what it is handed now carries that surface's own setting.
And a second thing the same fix uncovered
With the two rows properly the same feature, a gap showed up in the report: the register's add-on row had been winning lines for two releases and none of them were counted. The report was quietly under-reporting and nothing on it said so.
Both halves are the same underlying point. A feature that appears on two screens has to be one feature — one setting that governs it, one place it is counted — or it will eventually be two features that disagree, and nobody will find out from the screen.