search

ruoyann / pe

0 stars 0 forks source link

No error messages for extra parameters for commands that takes in parameters #10

Open ruoyann opened 3 years ago

ruoyann commented 3 years ago

This is what the UG had to say about extra parameters: image.png

However, the UG did not address the case where there are extra parameters when the command is supposed to take in parameters such as the below case where the user adds in an extra /p parameter and the app reads it as part of the description:

image.png

Command entered for the above image: add d/hi p/person goal/60 under the dashboard tab.

One suggestion to improve this can be stating in the UG that extra parameters for commands with parameters will just be read as part of the information provided for the valid parameter that it comes after. E.g specifically in the above case, the /p parameter will be read as an input to the /d parameter. This can help users understand the command better.

Or another way of solving this bug is to search for invalid parameters and throw an invalid command format error when add d/hi p/person goal/60 is entered under the dashboard tab.

nus-pe-bot commented 3 years ago

Team's Response

  1. That section in the screenshot mentioned "commands that do not take in parameters", which the add command under custom goals (the one used in the screenshot) is not.

(Further considerations, just for completeness:)

  1. Furthermore, extending this restriction to commands that also take in parameters is a non-trivial issue, as doing so would require parsing an input command for "/", looking at the character before that, and then determining if that is an extraneous parameter. This has the additional effect of not allowing users to not being able to specify fields with "/" characters, such as the custom goal with description "score 15/20 for 5 weekly tests" (rare, but not impossible). This limitation can be dealt with by specifying escape characters (like that used in the terminal or command prompt), but the implementation of that is also non-trivial (in addition to already being not in scope).

  2. Even if it was meant to fit the additional requirement in point 2 (which, once again, it was not), the bug would likely be of veryLow severity instead of low since it does not affect the usage of the user at all, i.e. the user would not read that section and then intentionally add extra parameters in expecting them to be ignored. Nevertheless, all of this doesn't matter because it isn't in scope in the first place.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Users may mix up the parameters due to the many commands available to the users, and accidentally entering an invalid parameter should be expected behaviour. Hence this invalid input should be accounted for and a suitable error message should be thrown to warn users that an invalid parameter has been used. If not, users may enter fields that do not make sense into the app and not realise that is wrong.

:question: Issue severity

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

Reason for disagreement: This is not a cosmetic issue as it can cause actual inconvenience to the users.