Incorrect note parameter leads to fitbook ignoring the note rather than prompting the user of incorrect command format

[ararchch]

Overview When the tag for note is incorrectly typed, fitbook does not seem to recognise that as the issue, but rather goes ahead to execute the command and ignoring the note. This is because the note is considered part of the address ( i think)

Steps to reproduce

• Start up fitbook
• Enter add n/Johffn Doe p/98765432 e/johnd@gmail.com a/John street, block 123,#01-01 ni/john from school

Expected behaviour

• Error message saying that command format is wrong

Actual behaviour

• Client is added to book

Potential solution Check for note or possible wrong formats before assuming it is the address

Screenshots

[soc-pe-bot]

Team's Response

We understand where the tester is coming from. Indeed it would be useful if users are corrected for minor typos, to the command prefix.

However, we are rejecting this for the following reasons:

1. It's not a bug.

According to the UG, any text is allowed, so this input would be considered valid.

2. This is intended behaviour.

Unless a new prefix is specified, all text is assumed to belong to the address.

Therefore, we chose to reject this bug.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: This issue is similar to the one reported for the phone number problem, hence the justification for why I disagree with the rejection is similar.

I understand where the team is coming from - the prefixes after the address are optional, so if the prefix is incorrect, fitbook will treat it as part of the address and add the user to the system.

While I can understand this sentiment as a developer, as a user I do not think that I will be able to justify this. The fact remains that I typed in a command with an invalid prefix but the system was unable to identify this error accurately.

I believe that as developers it is our responsibility to consider all such edge cases and make sure they are accounted for, and while it is arguable that this is a feature to be implemented down the line rather than 1.4 (depending on other features implemented in v1.4), I do think that this is an improvement of the product and should not be outright rejected.

Additionally, the 2103T website highlights the the system should detect easy to detect incorrect flags, and I would argue that ni/ instead or nt/ fits this bill.

In any case, I do feel that this is a valid improvement that the team can consider at least at some point down the line, and Hence I disagree with the teams position to outright reject the bug

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** While the team provided a reason to reject the bug, they did not provide one for why it should be downgraded to a low. I feel that this is a medium because typos are quite common especially in a CLI app, and this is a featureflaw that can affect many users.

---