search

alex-setyawan / pe

0 stars 0 forks source link

Name field is too restrictive #6

Open alex-setyawan opened 2 months ago

alex-setyawan commented 2 months ago

The name field can only take in alphanumeric characters and spaces, marginalising those with special characters like "Sarah-ann", "Muthu s/o Muthu", "Lala D'mitri" etc.

Here is the result of typing such a name

image.png

soc-pe-bot commented 2 months ago

Team's Response

Duplicate of #2339

The 'Original' Bug

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

Over restrictive name validation to be only alphanumeric - some legal names not allowed

Description Set the context.

This app is used in a clinical context, which mean patient names are usually saved in full. However, some legal names containing non-alphanumeric characters are not allowed to be added into the system.

image.png

Steps to reproduce

  1. Launch the application for the first time to load initial data.
  2. Run add ic/S9987654A p/98887777 n/Ramy s/o Shanmugam g/M b/02-10-99 e/ramy@gmail.com d/General Flu

Expected behaviour

To be able to add this patient and his details.

Actual behaviour

Disallowed.

image.png

Reason for severity

This may cause inconvenience to the doctors who are not able to save their patients' names containing characters like ' or / or -, when they are common amongst people.

[original: nus-cs2103-AY2324S2/pe-interim#2957] [original labels: severity.Low type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Such issue is of valid concern especially for foreign names that contains special symbols. The team has actually taken note of this particular use case and it was unfortunately not included in the planned enhancements. Hence Accepted.

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)

Reason for disagreement: [replace this with your explanation]

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Below is the description for an issue to be deemed to have medium severity: ![image.png](https://raw.githubusercontent.com/alex-setyawan/pe/main/files/e1434456-b6e3-4ac1-a2cd-1df41dee0527.png) This bug satisfies both conditions in the following ways. 1. Visibly, the product is still usable. 2. However, I am afraid this bug also satisfies the first condition, that it causes "occasional inconvenience": Given your user guide mentioned this app aims to facilitate some processes like issuing medical certificates and dispensing medicine (providing prescriptions), I presume this would include adherence to some sort of formal documentation process, for which exact full names would be used. In that respect, excluding special characters could cause more unintentional harm than good. How would a doctor issue a medical certificate without access to the patient's exact full name? If the patient is present, then he/she can just refer to the patient's IC, which renders the "name" field in the app less reliable. But what if the patient isn't? The app only stores the name with special characters redacted. To issue an official, authentic MC with the exact full name requires storing what, and where special characters are in the name, which adds additional work. What about when a doctor is copying a name from an online source (e.g. a national health database) into the app? He/she'd have to delete all special characters from the name for it to be registered by the app. Many names don't have dashes, slashes and apostrophes, yes. But what about commas? Many Singaporean names have commas (e.g. Tan Jing Jing, Lala). Perhaps deleting special characters for one name sounds trivial at first thought, but the cumulative time saved by including special characters would cause massive time savings in the long run, alleviating this "occasional inconvenience" brought up earlier.