Bug for adding name with invalid special characters

[Tsenrae]

Steps to reproduce:

1. add n/John Doe !@#$%^&* @!!@#!@#@!$ p/98765432 e/johnd@example.com a/John street, block 123, #01-01

Expected: Command should fail as the name contains invalid special characters that no name should have

Actual: Person with the name John Doe !@#$%^&* @!!@#!@#@!$ is added

[soc-se-bot]

Team's Response

Our team wants to accommodate for people with special characters in their names, and thus we have reduced the constraints for the input of names. Furthermore, people may also use special symbols and emojis in nicknames.

Thus, our app is behaving as expected.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Firstly, based on the screenshot below taken from your team's User Guide, the only point that you gave for the Name field is that it cannot be blank. You did not specify exactly what you are accepting/rejecting in the Name field, hence it is definitely a bug that I am able to add various special characters to a Name as names do not normally have special characters in them, which may lead to confusion and hence minor inconveniences for an average user when they type in such a name.

If intentions were clearer, you could have added an additional point Names can contain any special characters in the UG and gave an explanation accordingly. Therefore, though your app is behaving as expected, since you failed to justify your reasoning in the User Guide (as per your screenshot above about the usage of symbols in input values), this bug can be considered as an incomplete feature, which falls under type.FeatureFlaw.

As for your point about people using special symbols and emojis in nicknames, as said above, this is totally not specified in the UG. Furthermore, since your team's target user profile is small family restaurant owners, as specified in the DG, I would argue that full names would be important when it comes to customer's reservations as there will be times where you need their full names for verification purposes (e.g. owners frequently engage with various stakeholders such as suppliers, government bodies, customer information, supplier contacts, employee records, and financial institutions where the use of full legal names is mandatory. These interactions often require documentation that adheres to legal standards—standards that typically do not recognise special characters as valid components of personal names.). Allowing special characters in names could lead to inconsistencies that diminish the professional appearance of business documents, such as invoices or customer reservations, which are typically generated from this data. Thus, I believe that this is actually a Feature Flaw in your implementation of adding a Person if you were to argue that nicknames could be used instead. Therefore, I unfortunately cannot accept your argument for this point either.

---

## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---