nus-pe-bot
commented
11 months ago Team's Response
Error message is already able to specify that the user input error lies in the price part, and is saying that "price should be a non-negative integer...", which is guiding users on what are the correct inputs. It is definitely not a functionality bug. It is telling users the correct inputs to enter.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: This bug report is not incorrect.
According to the team,
Error message is already able to specify that the user input error lies in the price part, and is saying that "price should be a non-negative integer...", which is guiding users on what are the correct inputs.
By comparing the the command input edit-item s/1 i/1 p/5. 20, in particular the price input, as shown in the image, it correctly satisfies the conditions as stated in the error message. This means that this command should have been a successful command as the price input is considered a correct input, based on the error message.
Error message:
Price should be a non-negative number with 2 decimal places. Remove leading 0s if the price is 1.00 and above. Only have 1 leading 0 if the price is less than 1.00, eg. 0.50
The expected behaviour, which throws an error, is thus incorrect.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** Upon the command `edit-item s/1 i/1 p/5. 20`, this is the error message provided with the price input of `5. 20` (i.e. with a space between the digit 2 and the decimal point). > Price should be a non-negative number with 2 decimal places. Remove leading 0s if the price is 1.00 and above. Only have 1 leading 0 if the price is less than 1.00, eg. 0.50 I believe that this is a functionality bug, because the error message does not match the error, and hence the input does not work as expected, which is the definition provided by the website: > type.FunctionalityBug: A functionality does not work as specified/expected. The price input of `5. 20` actually satisfies the error message, which is supposedly to guide users on the correct inputs as mentioned by the dev team. Here's how the input matches: 1. > Price should be a non-negative number with 2 decimal places. The input `5. 20` is a non-negative number, and it has 2 decimal places of digits `2 and 0`. This is accordance to [Merriam-Webster dictionary,](https://www.merriam-webster.com/dictionary/decimal%20place) which states the definition of decimal places as the position of a digit as counted to the right of the decimal point. 2. > Remove leading 0s if the price is 1.00 and above. Only have 1 leading 0 if the price is less than 1.00, eg. 0.50 The input `5. 20` does not have any leadings 0s. As the error messages is actually "telling users the correct inputs to enter." (mentioned by the dev team), the price input of `5. 20` should have been accepted as a valid price input, which is the expected outcome. Therefore, this issue is thus more suitable as a functionality bug, as the behaviour of the app is different from the what is expected of the price input.
The price of 5. 20 follows the error message provided, but the correct error is that no spaces should be allowed in between. However, this error is not displayed to the user, and hence the error message does not correctly match the error.