The cart keeps a one-off, the bolt asks, the number works, and the same shop is not a different shop - #142
Merged
Conversation
Owner: "i chose different server then its logged out." Pinning an address by hand ended the session on ANY change, reasoning that a credential signed by the server being left behind is worthless at the new one. True between two shops. Wrong for the case this app is built around: one shop reached at its counter address and at its cloud address. Moving between those two is the ordinary thing a handset does when the Wi-Fi comes and goes - the whole hedge, failover and come-home design rests on it - and choosing the other one by hand cost a waiter their sign-in every time. The shop key tells them apart. It is a hash of the licence, identical in the shop own database and its cloud copy, recorded against every address that has ever proved itself with a sign-in. A known DIFFERENT key still signs you out, which is the half of the old reasoning that was right. An address nobody has signed into keeps the session and lets the server decide. If the token really is worthless there the answer is 401, and a rejected credential is already dropped rather than resent. Being wrong in that direction costs one refused request; being wrong the other way costs a password mid-service. Three tests. The first fails on the old code.
Owner: "quick sale not clickable until text added. after price enter it shows added to cart, when i go to cart its not showing. some issue." Two faults, and the second is the one that mattered. THE LINE WAS DELETED ON THE WAY TO THE SCREEN MEANT TO SHOW IT. A quick sale is INSTANT at the till, which is exactly what keeps it off the menu. The app then refreshes that menu whenever a screen loads, and three places delete whatever the menu does not contain: the products store prunes, and BOTH cart syncs drop any line whose dish they cannot find. So the item was created, the cart genuinely had it, the message was true - and opening the cart page refreshed the branch and removed the line on the way in. The row and the cart line now carry `instant`, and all three places keep it. A one-off has no dish behind it by design, and the line carries its own name and price, which is everything the bill and the kitchen ticket need. TWO CART SYNCS DOING ONE JOB. validateCartWithProducts and syncCartSilently are the same function twice, and the first fix landed in the silent one - which is not the one the cart page runs. The probe that found it printed the log line without the [silent] marker. Both are fixed; a duplicated function is a bug waiting for somebody to fix half of it. AND THE MARK WITH AN EMPTY BOX. It nudged the placeholder and did nothing else, which reads as a dead button - and a button that does nothing IS a dead button, however good its reason. It asks what the thing is called now, on the same sheet that asks the price: one habit, the keyboard in the same place, Enter doing the same thing. Four tests, including one that walks his steps exactly: add it, open the cart, and the line is on the bill. It fails on the old code.
Owner, twice: "i add number card but no use? how to use it?" and then "i tried to search with that number nothing happened." Nothing happened because the number lookup was only ever wired into the Add item sheet. The card is printed for the whole shop, and the menu screen - where most orders start - could not answer it. Half a feature, and from where he was standing, broken. Typing 33 now puts dish 33 first, under a "No. 33" heading, with every name match beneath it. The same rule the sheet follows: a number typed is a number meant AND sometimes a name, because in an Indian kitchen 65 is a dish. Both readings are offered and the waiter picks. The numbers come from MenuView.numbers over the shop own menu order, which is what the card and the sheet already use, so all three agree without anybody assigning anything. THE LOOKUP, NOT THE BADGE. Passing the numbers into the row renderer drew them on every line and turned every dish into "1Chicken Biryani" - two menu tests said so immediately. He asked to be able to USE the number, not to see it on every row of the screen he reads forty times a service. Two tests. The first fails on the old code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four faults from one testing session, each proven failing on the old code first.
The quick sale line vanished from the cart
"after price enter it shows added to cart, when i go to cart its not showing."
The message was true when it was shown. A quick sale is INSTANT at the till, which is exactly what keeps it off the menu - and the app refreshes the menu whenever a screen loads, with three places deleting whatever the menu does not contain: the products store, and both cart syncs. So the line was deleted on the way to the screen meant to show it.
The row and the line now carry
instant, and all three keep it. Worth naming: my first fix landed insyncCartSilently, and the cart page runsvalidateCartWithProducts. Two functions doing one job is a bug waiting for somebody to fix half of it, which is what I did.The bolt did nothing with an empty box
"quick sale not clickable until text added." It nudged the placeholder, which reads as a dead button, because a button that does nothing is a dead button however good its reason. It asks what the thing is called now, on the same sheet that asks the price.
A test caught a bug in that fix immediately: the picker still created the item from the search box, so with an empty box the till would have been handed an item with no name.
The number card did nothing
"i tried to search with that number nothing happened."
The lookup was only ever wired into the Add item sheet. The card is printed for the whole shop and the screen most orders start on could not answer it. Typing
33now puts dish 33 first under a No. 33 heading, with name matches beneath - the same rule the sheet follows, because65is also a dish name.I also drew the number on every row and took it straight back out: two menu tests said every dish had become "1Chicken Biryani".
Choosing a different server signed you out
"i chose different server then its logged out."
Pinning ended the session on any change of address. True between two shops; wrong for the case this app is built around, one shop at its counter address and its cloud address. The shop key tells them apart: same shop keeps the sign-in, a known different shop still ends it, an unknown address keeps it and lets the server answer 401 if it must.
340 browser tests and 512 unit tests, green.