Team's Response

Same issue of extraneous prefix reused yet again.

The 'Original' Bug

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

Invalid command accepted as valid input

To produce: Use an addp command but put in an extra INVALID prefix as shown in the screenshot. This works for prefixes not used in the addp command such as sd/ f/ o/ as well.

Expected: Error because it is an invalid command format.

Actual: No error and command is accepted as valid with the extra prefix going into the address field as shown in the screenshot. This flaw is quite jarring as invalid prefixes are not being detected, which could affect many users who accidentally enter a wrong command format which happens frequently.

_{[original: nus-cs2103-AY2122S1/pe-interim#3752] [original labels: type.FunctionalityBug severity.High]}

Their Response to the 'Original' Bug

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

Why are we rejecting this?

The command shown in the example is actually valid - we don't see why you want an error. cid is not a valid prefix for addp, but it CAN be a valid part of the person's address. I might be living in a block called cid on the 10th floor, so I might include cid/10 in my address. As long as the necessary prefixes for the command are present, we don't see why an error should be produced.

Why, regardless of rejection, is the severity wrong?

Even in the worst case, adding an extraneous prefix isn't 'jarring', since valid commands will still go through. This doesn't affect the user experience at all.

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: This issue is not a duplicate of the other bug as they cause different problems altogether.

The problem caused by this bug is that the wrong error message is shown to the user when a command with the wrong format is typed, which will mislead the user to look at the wrong place to try to find the problem with the typed command.

The problem caused by the "original" bug that this bug is marked as a duplicate of is that a command with the wrong format is being executed successfully with no errors, which is a wrong behaviour as an error message should be shown since the command format being used is wrong as it uses different prefixes from what is shown in the User Guide.

:question: Issue response

Team chose [response.Rejected]

[x] I disagree

Reason for disagreement: This is a bug because the wrong error message is being shown to the user. As seen in the screenshot, ePoch says that the name of the reminder is wrong, even though the name of the reminder follows the specified format perfectly. ("Test Wow" contains only alphanumeric characters and spaces and is not blank.)

The correct error message to be shown is that the command format is wrong, because from the screenshot, a different set of prefixes are being used as compared to the documentation in the User Guide for the editr command. Since the prefixes being used in the typed command are different, the command format is different and wrong as incorrect parameters are being given as input. Thus there should be an invalid command format error shown to guide the user to write the command in a correct format, as compared to the current error telling the user to examine an argument to the command which does not contain any problem.

:question: Issue severity

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

[x] I disagree

Reason for disagreement: The severity of this bug is definitely not "Very Low" since the bug is not only cosmetic and can affect the usage of ePoch by causing the user to look in the wrong place to try and correct the error.

Instead, the bug should be of "Medium" severity since mistakes do happen when people use apps, (especially an app like ePoch which contains many different prefixes) and when a mistake like this happens, it will cause inconvenience to the users since the error message is telling the user to look in the wrong place, wasting their time. The error message also does not hint anything about the command format, leaving it to the user to figure out that the command he typed in contains the wrong prefixes when compared to the command format in the User Guide. This also causes inconvenience to the user as the user would have to figure out and find the problem by himself due to the wrong error message.

TLChicken / pe

Incorrect error message for editr #9