Name field does not allow 's/o'

[althea28]

Steps To Reproduce

1. Enter command: add n/Hubert Blaine s/o Wolfeschlegelsteinhausenbergerdorff a/36 g/M i/S1234561Z p/98765432 e/johnd@example.com h/311, Clementi Ave 2, #02-25 apt/01/02/2024 13:30 t/Patient t/A+

2. Press enter

Expected

This is the real name of a person. Given that patients' healthcare data is to be saved, it is expected that the full, legal name of a person should be allowed and reflected. Disallowing 's/o' in a person name can cause a major problem since the input is expected to match the legal name of the person.

Actual

Error shown: Names should only contain alphanumeric characters and spaces, and it should not be blank 's/o' is disallowed in names, although some people's names do contain this.

[soc-pe-bot]

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Names containing s/o, d/o or @ are disallowed

Names containing s/o and d/o are common in Singapore, especially in the Indian community. @ in names is a little more rare, but they also do exist locally. As the app stores medical information, which must ensure the highest accuracy, it is important to allow all, or at least common, valid names in Singapore.

Here is an example of s/o being disallowed.

Alternatively, it could have been mentioned in known issues or FAQ, to inform users about such circumstances, such as requiring a change of s/o to son of.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#1723] [original labels: severity.Medium type.FeatureFlaw]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Since we are using '/' as a command limiter, we decided to disallow it as it will cause issues when parsing names with symbols. But encountering such names is infrequent, hence we decided that it should be a low severity.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** While I understand the technical limitation posed by using '/' as a command delimiter, I respectfully disagree with the decision to classify this bug as low severity. This application is designed for healthcare purposes, where ensuring data integrity is paramount, and a patient’s name is a critical piece of sensitive information that must match their legal name exactly. Disallowing 's/o' in names could lead to data mismatches, which may cause downstream issues such as incorrect identification of patients in legal or medical documents, and rejection of records when integrated with systems requiring exact legal names. As per our [course website](https://nus-cs2103-ay2425s1.github.io/website/admin/tp-pe.html#tp-practical-exam-pe), it is specifically stated that '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'. Given that this app is for healthcare purposes, I believe that it is reasonable to expect the full, exact legal name of the person here.  Additionally, while names containing 's/o' may not be frequent, they are not negligible, and the implications of failing to store accurate legal names in a healthcare application cannot be understated. Hence, I believe that the reason given by the developer team regarding the 'command delimiter' is insufficient to reduce the severity from medium to low. The severity of this bug should be at least classified as medium to reflect its potential impact on the application’s primary purpose.

---