search

Bisceto / pe

0 stars 0 forks source link

Find feature no error message for incorrect command #1

Open Bisceto opened 1 year ago

Bisceto commented 1 year ago

Currently, I have 1 lecture "Week 1" with tags "intro" in CS2103.

image.png

In the CS2103 directory, I typed in the command "find intro /byTag" which was able to find the said lecture.

However, when I typed in the command "find intro /bytag" in the CS2103 directory, instead of giving me an incorrect command format error message, I got a display saying 0 lectures listed.

image.png

This can be confusing for the user, as a small capitalisation mistake can lead to them believing they don't have such a lecture. An appropriate error message should be displayed instead.

This error applies to all other commands that uses the /byTag parameter

nus-pe-bot commented 1 year ago

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Although #3888 is for a different argument typo they both describe the same issue which is caused by a design decision we standardised across all commands as specified in our UG (extraneous arguments will be ignored).

Disputing severity

The only command that uses "/byTag" is the "find" command. The issue occurs when the user makes a typo and fails to catch it. This is expected to occur rarely once the user gets use to the "find" command and also likely to only cause minor inconveniences. Hence a low severity is more fitting.

Disputing bug type

In the "Command Syntax" section of our UG, it is mentioned that:

  1. Extraneous arguments will be ignored.

Let's break down the command:

find intro /bytag

In this case, "find" does not expect an argument named "/bytag". Hence, the argument "/bytag" is ignored. The command thus becomes:

find intro

Since the tester was in the lecture context, this is interpreted as find any lecture in module with code "CS2103" with a name that begins with "intro". Since there are no lectures that begin with "intro", we encounter the message "0 lectures listed!".

There is hence no functionality bug. Everything is as described in the UG.

It does, however, possibly imply a feature flaw which we will explain in #3888.

The 'Original' Bug

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

Incorrect parameter names not showing error message

Expanding off the previous error about the Find Command, I realised this is applicable to all parameters.

I have a lecture called "Week 1" in "CS2103". When I try to find said lecture in the root directory with the following command "find Week 1 /Lec CS2103" It shows me that there are 0 lectures.

image.png

Again, this can confuse users. When I use "/Lec" instead of "/lec", it does not show any error message about an invalid command.

[original: nus-cs2103-AY2223S2/pe-interim#3420] [original labels: type.FunctionalityBug severity.Medium]

Their Response to the 'Original' Bug

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

Disputing severity

A medium severity is a too high for this issue. The issue might occur when the user makes a typo (e.g. accidentally typing "/Lec" instead of "/lec") and fails to catch it. This is expected to occur rarely and thus a low severity might be more fitting for this issue.

Disputing bug type

In the "Command Syntax" section of our UG, it is mentioned that:

  1. Extraneous arguments will be ignored.

Let's breakdown the tester's command:

find Week 1 /Lec CS2103

In this case, "find" does not expect an argument named "/Lec". Hence, the argument "/Lec" and it's value is ignored. The command thus becomes: 

find Week 1

This is interpreted as find any module with code or name beginning with "Week 1". Since there are no modules with code or name that begins with "Week 1", it shows that there are 0 modules. Note here that the tester likely misread the command output message. It is not that there are "0 lectures" as the tester described, but instead there are 0 modules. This can be seen in the screenshot provided by the tester:

image.png

There is hence no functionality bug. Everything is as described in the UG.

It does, however, possibly imply a feature flaw.

Justifying not in scope

Our design decision was base on consistency. If a user were to enter an argument by mistake for a command like the "exit" command, it should not produce any error and execute as expected (i.e. exit the app). The downside is that situations like the one tester described can occur. Perhaps, a middle ground would be to execute the command but give a warning if an invalid argument was specified.

Changing to this behaviour would require changing all commands to comply with the standard. Thus rectifying it is less important than the work that has been done already. The current behaviour is also explicitly specified in the UG. Hence, we feel that this is not in scope.

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: [replace this with your reason]

## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]