Allowing of Custom Prefixes for Remarks

[Mohammed-Faizzzz]

the following command: add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/tall r/some customprefix/ is entered as valid despite the use of a custom prefix. This might be a problem when someone unintentionally uses the wrong command (eg intending to use insurance prefix ai/ but accidentally using add command. The lack of error handling might allow the wrong addition to go unnoticed.

[nus-se-bot]

Team's Response

Hi there, thanks for bring this issue up.

First, I'll explain the bevahiour of the example you used, this is a behaviour of our application not detecting the custom prefix/ as a valid prefix, and hence the value is being considered as part of the remark value (i.e. the remark value in your example would be some customprefix/, which is indeed a valid remark. Hence, the command executes successfully.

In order for the application to detect such cases, it would mean that any values in the form of xxx/ would need to be detected as a prefix, which I think will not bring any benefits to the user as users can no longer input any values in such a form. There is also a relevant section in the course website that describes this behaviour:

Use of symbols in input values: It is acceptable to disallow certain characters in input values if there is a justification (e.g., because using those symbols in an input value makes the command harder to parse), but they can still be considered FeatureFlaw bugs if they cause inconvenience to the user. For example, disallowing s/o in a person name because / is used as a command delimiter can cause a major problem if the input is expected to match the legal name of the person.

Even if we were to only detect prefixes that exist in the system(e.g. ai/), we think it would be impractical too, consider the common cases such as using the command terminal, when executing a command with additional flags, only flags associated to the command would be detected, and not all available flags within the system(take the unix system as an example, it does not detect all the flags off all the available command, but only flags associated to the executing command).

As a conclusion, I think that allowing values of such form has more benefits than disallowing it, hence I decided to reject this bug.

Justifications on severity and bug type choice(in case tester and tutor disagrees with the rejection of this bug):

Why we think it is a FeatureFlaw rather than Functionality bug:

• This is the expected way our application functions, we never specified that anything in the form of xxx/ would be recognised as a prefix and be parsed accordingly.

Why we think that it is severity.Low rather than severity.Medium:

• This current feature flaw is just that when users inputted additional values in the form of xxx/, our application would not detect it as a prefix. However, we think that the chances of users inputting a wrong prefix with the intention of actually using it as a prefix is relatively low.

  Items for the Tester to Verify

  :question: Issue response

Team chose [response.Rejected]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :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.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---