search

Bisceto / pe

0 stars 0 forks source link

Incorrect parameter names not showing error message #2

Open Bisceto opened 1 year ago

Bisceto commented 1 year ago

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.

soc-pe-bot commented 1 year ago

Team's Response

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 response

Team chose [response.NotInScope]

Reason for disagreement: [replace this with your explanation]

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