nus-se-bot
commented
1 year ago Team's Response
Deals with the ordering of flags. Also, UG already states the correct ordering of the format.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Incorrect output when input is in wrong order happens with list command as well
Should be handled as an exception or input be read as appropriate using flags
[original: nus-cs2113-AY2223S2/pe-interim#1260] [original labels: type.FunctionalityBug severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Should be a featureflaw as it deals with the order of the flags.
Severity should be low as it only appears in rare situations when a user does not follow the intended formatting. It does not affect the normal operations according to the tester's bug report.
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)
- [x] I disagree
Reason for disagreement: conditions to mark under duplicate:
(a): With regard to point a, this is definitely not the EXACT same bug as it happens for a different command.
(b): See below for teams code on how parser is implemented, each command has its own method where the relevant parsing is done; hence, solving one doesn't resolve all the others as they will need to make changes to all the other methods as well.
## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** In command-line interface (CLI) based applications, the order of flags is usually not important which includes most of the git commands that can be used via CLI and some users that want to use CLI based apps may be accustomed to this practice, and users expect to be able to specify parameters in any order they choose. Therefore, if there is no explicit specification regarding the order of parameters in the user guide or documentation, users may assume that they can use them in any order. Nowhere in the UG is it stated that the commands must be executed in a specific order, which is a crucial point to consider when the program uses flags to track input. However, if the program does NOT use flags, it can be assumed intuitively that the commands need to be in a certain order. In light of this, it opens the question of why flags are used if the order cannot be changed. Additionally, if the order does matter, it may be better to eliminate the use of flags altogether, as this would remove the need for users to type the special character "/" and reduce the number of characters they need to input by six. This would optimize the program for its intended audience and facilitate faster typing. Guidelines describe feature flaw as: Missing features and problems in how a feature is designed are considered feature flaws i.e., type.FeatureFlaw. I did accidently identify this bug as a functionalityBug however as the team noted this is indeed a feature flaw and cannot be rejected.
## :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.High`] - [x] I disagree **Reason for disagreement:** In command-line interface (CLI) based applications, the order of flags is usually not important which includes most of the git commands that can be used via CLI and some users that want to use CLI based apps may be accustomed to this practice, and users expect to be able to specify parameters in any order they choose. Therefore, if there is no explicit specification regarding the order of parameters in the user guide or documentation, users may assume that they can use them in any order. Regarding the issue with the clear command in the screenshot, it can be a significant inconvenience as it may result in the accidental deletion of a year's worth of data, with the possibility of deleting the wrong year altogether. This could render the user's work obsolete, and force them to start over from scratch. Furthermore, the program does not even provide an error message when the parameters are given in the wrong order, and simply proceeds with the command. Based on these factors, it is reasonable to consider this issue as a high or at worst a medium severity issue, rather than low. This issue indicates a failure to implement proper input validation measures. This same issue happens within all other commands that take in. more than one parameter. This is a grave inconvenience that warrants a high severity. While it may be appropriate to assign a low severity rating to the issue occurring with the "list" command, it would not be appropriate to assign the same severity rating to issues occurring with more interactive commands like "clear". Such commands have a greater impact on user inputs and outcomes, which can lead to significant inconvenience. Therefore, it is essential to consider the potential impact of such issues and assign an appropriate severity rating based on the severity of the consequences that could result.
Change order of parameter should throw error or handle the inputs as appropriate as flags were used, instead of following through with wrong output