nus-pe-bot
commented
4 years ago Team's Response
Not a flaw. Wait, how is this missing functionality?
Why exactly should we refuse a transaction in the future? What if you know you're already going to spend this amount in the future? Who are we to stop a user from entering a future transaction?
I feel like if we had this restriction, someone would've filed the opposite bug: should allow transactions in the future to be filed.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I do understand the concern that transactions may be added much in the future or past. However, there may be instances of users accidentally entering an incorrect date (for example "201" or "20190" instead of "2019") without even realising it. Due to this reason I believe that appropriate date validation functionalities are missing from this add transaction functionality. However, I do agree that this is a minor detail and might cause rare inconveniences for the users and hence I agree with the tag of severity.Low. But nevertheless, I still feel that this lack of validation could cause inconveniences for the user.
:question: Issue severity
Team chose [severity.Low].
Originally [severity.High].
- [ ] I disagree
Reason for disagreement: [replace this with your reason]
The restrictions set for the date are not very clear. If this app is keeping track of transactions, it should keep track of transactions in from the present date to any past date, and if absolutely necessary to near future dates at most. However, currently a transaction from the year "2200" can be added, which by right should not be possible. It could be a possible user oversight or inputted by accident in which the app should have a warning. The date restrictions were not mentioned in the user guide either.