nus-se-bot
commented
6 months ago Team's Response
It is stated in our User Guide that editing products on the product menu will not affect or change the products on active orders. (Under the edit menu feature) We have previously thought about this and it is the intended behaviour of our app. Our rationale is that once products have been added to the orders, it is said to be confirmed and ready for preparation, so they should not be edited any further. Even if the product is no longer existing on the menu, the one on the active order is said to be in the process of baking already. (So it is like the last few batches of that type of product)
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Hello, thank you for your response.
However, I disagree.
Although it is mentioned in the User Guide that editing the product menu will not change the products on active orders, this doesn't take away from the occurrence of faulty application behaviour / functionality bugs due to Strack being designed in such a way. The expected behaviour put forth by the team causes logical problems that are not handled by Strack, hence it is insufficient to inform the user of this behaviour.
Firstly in response to the rationale given that :
Once products have been added to the orders, it is said to be confirmed and ready for preparation, so they should not be edited any further. Even if the product is no longer existing on the menu, the one on the active order is said to be in the process of baking already. (So it is like the last few batches of that type of product)
If that was the intended behaviour, Strack should disallow editing of the products added to the orders in the first place or explicitly handle such behaviour -- which it currently does not. Currently, Strack allows the user to edit a menu product that is currently part of an active order. It is also not reasonable to assume that the user is in the process of baking the orders already, as the default order creation stage is 'Under preparation' even if the user has started working on it or not.
Next, the self-contained problem of this bug is that it could cause information lost that the user is unaware of. By allowing an order to contain a non-existent product, the user is unable to trace back to any original menu item for confirmation. The user is also unable to reference which item had been edited should they want to revert their decision to edit it. Since there is no error message or warning within the application itself to tell the user that the menu item they would like to edit already exists in certain orders, the user may unknowingly edit an item they didn't want to.
For example, the user now has an order for a cake for John Doe. However, there is no item on the menu that matches this order, as the original cake Cost:$15 Sales:$20 had been edited to strawberry muffin Cost:$15 Sales:$20.
In the worst case scenario, a new product could be added or a product could be edited to have the exact same name as the previously edited item. Here, a new item was added as cake Cost:$1 Sales:$30 which would cause great confusion for the user if they hadn't noticed or were aware of this.
Furthermore, in reference to the bug labelled a duplicate to this, a relevant point (also explained there) would be as follows:
Allowing orders to have nonexistent items causes Edit to break. Example: New product has same name as nonexistent product
Due to the original cake Cost:$15 Sales:$20 item no longer existing, if the user inputs edit o/1 m/3 pq/20 which refers to the newly added cake product, the cake quantity does change in the order but not the price. This is unexpected as there shouldn't be a reference for the no longer existing cake Cost:$15 Sales:$20, as item 3 on the menu is not referring to the same cake item in that order. In fact, according to interpretation of "edit" changing the quantity of a menu item the order has, there should be two cake items on this order instead of 1, since the new cake item is of $30 rather than $20.
This would cause great confusion to the user and break the functionality of this edit o/ORDER feature.
Thus, as according to the team's original intention, if there is allowance of an order having a nonexistent item, this would cause the edit feature to possibly not work correctly in the event of a new product having the same name as the now non-existent item.
Hence, I believe that this is a functionality bug as this legitimate user behaviour is not handled properly or as expected -- 'expected' being in the sense of the functionality and effectiveness of the application. It is also classified as severity.High as it creates major problems for users that defeats the purpose of Strack as a way to keep track of orders well.
If I edit a menu item's name, eg here from cupcake to muffin, the Order now has a "Cupcake cost" even though there is no longer any "Cupcakes" on the menu. There is no warning or error, and this can cause great confusion to a user who has an order for a product that no longer exists.
Worst case, there is information lost that the user is unaware of.