search

aliciatay-zls / pe

0 stars 0 forks source link

Valid dates not being accepted, inconsistency in dates accepted #3

Open aliciatay-zls opened 3 years ago

aliciatay-zls commented 3 years ago

image.png

image.png

image.png

image.png

From the UG, 31 should be a valid date for FastScheduler but some dates e.g. 31 December are not being accepted while others e.g. 31 January are (1st two screenshots). Meanwhile, invalid dates such as 31 November (3rd screenshot) are accepted.

aliciatay-zls commented 3 years ago

image

same across all commands involving dates e.g. "add shift"

nus-pe-bot commented 3 years ago

Team's Response

No response provided.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Inconsistent shift date instructions in UG

Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.

As shown here, the shift date instructions are different in the same section of the UG, this may cause confusion to users when they input the date and encounter error even though they are following your instruction by inputting DDMMYYYY.

Screenshot 2021-04-16 at 5.37.26 PM.png

[original: nus-cs2113-AY2021S2/pe-interim#265] [original labels: severity.High type.DocumentationBug]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

No response provided.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: This issue is on the Functionality Bug that the user cannot key in certain valid dates (31/12/2021) while some are ok (31/01/2021). At the same time, they are able to key in invalid dates when they are not supposed to (31/11/2021).

The other issue on the Documentation Bug is on a different bug (UG states that the date parameter should be in the format of DDMMYYYY instead of DD/MM/YYYY) - missing "/".

:question: Issue type

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

Reason for disagreement: image.png

This issue is on the inconsistency of input validation which is a Functionality Bug (incorrect commands are not handled), while the other issue is on inconsistency of UG input format, a Documentation Bug. Maybe the issue headers were too similar.

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.High]

Reason for disagreement: Minimum should be Medium severity. This issue indicates a serious logic flaw in the parsing of commands involving dates. By default using LocalDate should automatically throw exceptions for invalid dates, and at least round down for special dates like 28 February (31 Feb --> 28 Feb).