search

mitchmalvin1 / pe

0 stars 0 forks source link

Undefined behaviour when user types something during `review` #13

Open mitchmalvin1 opened 1 year ago

mitchmalvin1 commented 1 year ago

Screenshot 2023-04-14 at 5.15.19 PM.png

Instructions in the UG only mentions that users can press enter to continue, but did not say anything about whether the user can actually type something at this stage (seen from the extra i that user types). As it turns out, user can indeed do so but this is unspecified. This is not trivial because user will need to know this as they might want to type the answer out themselves when they are trying to recall the answer

nus-pe-script commented 1 year ago

Team's Response

We do add the (ENTER to view answer), so all the user needs to do is clearly simply [Enter].

Well... the user can choose to type other things before the [Enter], we will simply ignore them, for reasons please see the linked issue.

The 'Original' Bug

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

Certain words are ignored input

Input:

add [RANDOM WORDS] /q [QUESTION] /a [ANSWER]

add can be replaced with clear, help, review, bye

Expected:

The input is in an incorrect format.
You can view our user guide or type help to see the correct formats for commands.

==========================================================

Actual:

You have added the following card:
Q:[QUESTION]
A:[ANSWER]
==========================================================

Proof:

image.png

Cases where extra words are not ignored: list all [RANDOM WORDS]

image.png

Apologies if this is an intended behaviour.

[original: nus-cs2113-AY2223S2/pe-interim#2026] [original labels: severity.Low type.FeatureFlaw]

Their Response to the 'Original' Bug

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

It is the intended behavior for the program to ignore the text not behind any option function (eg: /q). I believe that our user guide already indicates that when adding a question by add /q QUESTION /a ANSWER, only QUESTION and ANSWER would be recorded into the system.

The program tries its best to recover from user mistakes, by ignoring options that are not relevant to its operation, instead of throwing completely and forcing the user to retype. It doesn't allow typo so you can't get away with reviuw but it will ignore arguments it don't care if they exist, and that's entirely by design.

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 is not a duplicate issue with the bug mentioned. The other bug was about trailing arguments that do not belong to any options in a command such as add or list. This bug is after the commandreview` has been run.

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** Even though the UG mentions that the user needs to hit Enter to view the answer, there is still no clarity at all on whether user can type his own answer before entering (nor is there any sample output). Since this is not considered a corner case / extreme case as users are very very likely to do this in real life, this behaviour should be specified (if it is even intended).