nus-se-bot
commented
2 years ago Team's Response
Not a priority since flags are suppose to be precisely used as stated. The convertion to lower-case for commands is an added feature that convenience users. Does not deviate from the fact that the commands should be used as stated.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: I believe this bug is still a valid concern that is within the scope of your project. Ensuring flexibility of flags improves convenience but this is even more so important as your target audience is fast-typists. If there is varying rigidity as to what is acceptable as a "flag":
1) You confuse the user as to what is allowed and what isn't 2) Your already long commands are made even more complicated as the user has to keep in mind of this inflexibility 3) Frequent error messages for something like this only frustrates users
This wouldn't have been a problem if your commands were small but, your commands are way too lengthy. So, it is the responsibility of the dev team to ensure that this convenience is some secondary concern as you are still making a product for the user's sake and not yourself.
Hence, I would perhaps reconsider this as a feature flaw with a MEDIUM severity as you can still use the product but it can cause some inconvenience.
I have taken a screenshot from the module website and it clearly states that this is a valid concern:
In the picture, you can see that for any errors in the parameter "/day", you have placed safeguards to prevent it from being uppercase. But in the case of "add-day", I can type it in upper case and the command still passes. Why not implement the same thing for "/day" for uppercase is converted to lowercase automatically using (to.Uppercase)?