No clear syntax for client names

[mhdsyfq77]

Any name (even invalid ones like 1111) can be entered as a name.

To reproduce: Type client add n/1111 p/999 e/syafiqeee123@gmail.com a/6332 Punggol Central c/JP tz/UTC-08:00 ce/2-3-2020

Expected: Message telling user to enter non-numeric names.

Actual: Command accepted.

Screenshot:

[nus-pe-bot]

Team's Response

Thank you for the report. However, this is actually a feature as the user can encounter clients of various names, which may not conform to traditional naming conventions in the western world. Hence the user has Unrestricted freedom in naming his clients. This gives the user freedom to choose his own alias for his clients as well. Hence we do not see any need to limit the naming choices the user can have. This behaviour was also inherited from AddressBook3 as shown in the screenshot below, thus we have rejected this bug report.

We have changed the severity to VeryLow as this does not detract from our intended feature design.

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: Thank you for the feedback. I agree that the bug was inherited by AB3, however, it should have still been handled to cater to your product.

If I may elaborate, with regards to TBM, I am highly certain that if a user has a huge number of clients, he would have troubles remembering them if he constantly uses random aliases, for example, in the form of numbers e.g., "1111". What if he were to have 2 other clients with names "111" and "11111", and all these clients have random email addresses, like "someonecool@gmail.com" and they all live somewhere in Serangoon, how certain are you the user would be able to distinguish between who is who? Example:

Perhaps if you mentioned that an alias was an optional field a user could enter for easier identification of clients on top of the client's name then it would make more sense. However I feel that the name is a basic form of identification and needs to be correct, otherwise it defeats the purpose of your product of keeping track of the user's clients.

---

❓ Issue severity

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

• I disagree

Reason for disagreement: I respect the decision to change the severity of this issue to severity.VeryLow, however, I disagree that this issue is purely cosmetic and does not affect usage and I still believe that the severity should remain as severity.Low and my justification is as follows:

As I mentioned in my Issue Response, users might have troubles identifying who is who if random aliases are given to clients (rare as normally users would simply just use proper names) especially if the user has a huge number of clients, so it may cause minor inconvenience.

---