nus-pe-bot
commented
3 years ago Team's Response
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 response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: The type of counter-example being provided is extremely unlikely to happen. Furthermore, this specific counter-example would not happen at all, because ePoch is targeted towards NUS students, and there is no such block named cid in Singapore.
It is extremely unlikely that a user would be typing a command with such an extra prefix intentionally, such an example is much more likely to happen when the user makes a mistake while using ePoch and accidentally types in a prefix that was not needed, due to the sheer number of different prefixes and commands that are available for ePoch. Mistakes made can be quite common especially for new users, so the possibility of this being a mistake far outweighs the chance of the command being intentionally typed with the extra prefix that is not supposed to be used with this command.
A worse part is that this does not just happen for the cid/ prefix, it also happens if any of the other prefixes of ePoch are used extraneously in this command even though it is not part of the command format according to the User Guide. This flaw is quite jarring as any invalid prefixes are not being detected. This would lead to an even higher chance of mistakes triggering this bug.
You said that:
As long as the necessary prefixes for the command are present, we don't see why an error should be produced.
If extra prefixes that are not supposed to be used with this command are present, the command format is considered to be wrong. This is parallel to how the command formats are also wrong if there are missing prefixes. This is because when there are extra redundant prefixes, the command format does not follow the format and use the same type of prefixes as shown in the User Guide for the specific command. The extra redundant prefixes makes the typed command have a different format than what is shown in the User Guide, since the prefixes are of a different type. The command executes successfully even though it uses different prefixes from what is shown in the User Guide, so this is a big problem.
Hence there should be an error informing the user that the prefixes being used when typing this command is wrong in order to help guide the user to use the command with the correct format, with the correct set of prefixes.
The worst part is that this invalid command successfully executes, even though the format is wrong due to incorrect prefixes. The user might not even know that he typed in the command wrongly. Thus this is a big bug.
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: There is no way that this bug could be considered as a bug with "Very Low" severity, as it is a flaw that could potentially affect most new users using ePoch, since the bug could easily trigger when such a mistake is made, and mistakes happen frequently among new users since they are unfamiliar with the app.
This is a huge issue because it does not just work for cid prefix. The problem is general and happens with any other valid prefix in ePoch (such as sd/ f/ o/) that are not being used in this command. This makes the possibility of a mistake triggering this bug much more likely.
This is a major problem because the wrong command executes successfully and there is no error being shown even when the command typed is in the wrong format. If the wrong command format results in the wrong error being shown, maybe the severity could be lower as the error would prevent the wrong command from being executed successfully. However, in the actual case, there is no error being shown at all. This could cause a HUGE problem to the user as the wrong command executes successfully, possibly modifying the data in a way that the user did not intend to. (An example can be seen in the bug report screenshot, where the valid prefix cid/ is being put into a person's address even though the command format is wrong. This is highly likely to be a mistake made by an inexperienced user.)
Then the affected user would have to clean up the damages that the wrong command has caused, affecting the user experience in a negative way. In the end, the user may not even know what went wrong, because there was no error shown in the first place to alert the user to whichever command was entered wrongly.
Since this bug can affect many users - old or new (they just have to make a mistake!) and is a jarringly huge problem (no error is even shown even though the command format is wrong!!), this should be considered as a High severity bug according to the criteria.
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.