search

orzymandias / pe

0 stars 0 forks source link

add -c John Doe d/4000-02-02 t/13:30 #5

Open orzymandias opened 3 years ago

orzymandias commented 3 years ago

Running the command

add -c John Doe d/2000-02-02 t/13:30

add -c John Doe d/2100-02-02 t/13:30

Adds the same card image.png

App does not properly distinguish dates when they are more than 99 years

nus-pe-bot commented 3 years ago

Team's Response

Thank you for the issue. Although limiting the dates will seem like a good feature, we feel that it is unnecessary since TAs are most likely only going to use the app during the semester. The same goes for showing the entire year. 1999 and 2099 will only be confusing in a macro perspective, and if I am a TA in 1999, I would not confuse it for 2099.

The year format has been simplified to help the tutors instantly recognize the small differences in the year (as usually there will only be 1 year differences e.g. 20/21 for this Academic Year). The other implied bug (that then the users should not be able to enter years that are more than 99 years apart) is addressed in a separate bug report, so we will not go deeply into that. This specific issue, however, is actually expected behavior.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Thank you for your response. I completely agree with your view that no TA in their right mind will enter 2020 as 2220 or be confused between these 2 dates. However, what you may fail to consider is that 2220, 1020, 2920 are all possible typos which are all 1 keystroke apart that a TA may accidentally enter and the app will still show them as the same date.

The fact that the application does not distinguish bugs which are 99 years apart is not implied but rather explicit in the report. As I did not author the other bug report, I am unable to see your response pertaining to this issue. Regardless of your response, I do think this is a significant issue as this limitation has spillover implications on other commands. An example is how view -cp and view -mcp which retrieves items which occur before the current date. A TA who has made the typo will not know why his consult in the past is never retrieved because he entered 2020 as 2920 and the app does not distinguish them nor disallow entering dates which are out of a realistic range.

:question: Issue type

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

Reason for disagreement: The team did not explain the recategorization but I feel it is a functionality bug as it does not handle legitimate user behaviour - typos

image.png

:question: Issue severity

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

Reason for disagreement: I am repeating this portion because it is relevant to the argument of the severity of the bug:

This is a significant issue as this limitation has spillover implications on other commands. An example is how view -cp and view -mcp which retrieves items which occur before the current date. A TA who has made the typo will not know why his consult he thought was in the past is never retrieved because he entered 2020 as 2920 and the app does not distinguish them nor disallow entering dates which are out of a realistic range.

The team did not explain the lowering of severity but I think this is a medium issue and as it does cause occasional inconvenience and affects normal operations - the retrieval of consultations/mastery checks in the past.

image.png