Open debbiextan opened 4 years ago
Issue #1453 and issue #1451 are same issue: an invalid dish name such as "rock 150" cannot be recognized.
Reason of not within scope:
Our program targets at the users who are chef. We do not care about how the order is generated. This should be from the perspective of customers or the personnels at the front desk. The chef simply input the order coming from restaurant machine (if ordering is done automatically) or the front desk. So the mentioned flaw that is unlikely to affect normal operations of the product, as it only appears in very rare situations that the chef input has typo.
I admit it would be better if we could deal with invalid dishes name input. However, as the recipe book feature is done at very last stage, there has few time left to combine order and recipe featuers together and check if the ordered dish is in the recipe book (or menu).
Our product document is matched with the outcome. We never mention in anywhere of UG, DG that the ordered dish has to be found in the recipe book.
Our product in v2.0 will fix the issue you report. The feature 3.7 in UG included the build-up of linkage between order, recipe book, and ingredient. That is, for one order, we calculate the amount of each ordered dish and seek for the recipe for that dish. At this stage, we would be able to recognize which dishes are valid or invalid as we access the recipe book and check. If the dishes can be found in the recipe book, we would like to check if there are enough ingredients stored in the fridge.
I did consider for limiting the dishes name to only characters. However, some dish does include numbers within its name. To make it general, we accept all string as a valid dishes name at current stage.
Team chose [response.NotInScope
]
Reason for disagreement: [replace this with your reason]
Team chose [severity.Low
].
Originally [severity.Medium
].
Reason for disagreement: [replace this with your reason]
Input: add -n maggots 3
Result: accepted.