Adding/Editing client info with non existent dates are accepted

[jiayi1129]

Steps to replicate:

1. Run add -c John Doe -pn 98765432 -e john.doe@gmail.com -a xxx RdSingapore -o 1 1 02/30

Current behavior: Adds the client with the order with date February 28 Expected behavior: Error message shown to warn the users that February 30 does not exist

This can cause the online seller to accidentally add a wrong date for the order (perhaps trying to add for March 30, but mistype for February 30)

[nus-pe-bot]

Team's Response

UG omitted mentioning that invalid dates would be automatically rounded down. Hence, this here is accepted but as a documentation bug instead

Items for the Tester to Verify

:question: Issue type

Team chose [type.DocumentationBug] Originally [type.FeatureFlaw]

• [x] I disagree

Reason for disagreement: I disagree. If that is the case, almost any other bugs can be classified as a documentation bug then. This should be a feature flaw because it is an unexpected implementation case and a design flaw. In fact, for an application like this, the date should not be rounded down and instead display the error message as mentioned in my original bug report. It is more likely that the users type in the wrong date and month (Like 02/30 instead of 03/30). Instead of having the wrong dates to be rounded down, there should be checks to prevent such a possible user input.

---

:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

• [x] I disagree

Reason for disagreement: There is no explanation by the team why there was a downgrade of severity. In my explanation of why this should be a feature flaw as opposed to a documentation bug as proposed by the team, I mentioned that

"I disagree. If that is the case, almost any other bugs can be classified as a documentation bug then. This should be a feature flaw because it is an unexpected implementation case and a design flaw. In fact, for an application like this, the date should not be rounded down and instead display the error message as mentioned in my original bug report. It is more likely that the users type in the wrong date and month (Like 02/30 instead of 03/30). Instead of having the wrong dates to be rounded down, there should be checks to prevent such a possible user input."

You can imagine that in an established development environment with a QA involved, this will be flagged easily as a medium bug that needs to be rectified before production since this is not the intended behavior of the system. The system should add exactly what date is keyed in precisely instead of correcting it to the closest date for accuracy sake. Especially for CLI clients, what we type in to the command line should be accepted as the final truth of the input, and the inputs should not be conveniently changed by the inner validations.

---