search

maze508 / pe

1 stars 0 forks source link

Restrictive Unique Contact Identifier #5

Open maze508 opened 3 months ago

maze508 commented 3 months ago

Details

The App checks for unique identifiers simply through Name. This is quite restrictive as there may be multiple patients with the same name, i.e Joshua Tan is a really common name. A person should be uniquely identified through a combination of fields, like Name + Phone No.+ NRIC etc ... instead.

nus-pe-script commented 3 months ago

Team's Response

In our DG, we mentioned that this is a known issue and we are planning to implement this functionality (allowing the addition of the same name) in future iterations. Hence, we would like to reject this bug.

image.png

The 'Original' Bug

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

Names overly restrictive

Only allowing alpha numeric characters in names is overly restrictive, many legal names exist where '/' are needed. some non alphanumeric characters should be accepted.

Steps to reproduct:

  1. Run in CLI ' add n/John s/o Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 k/Joe s/o Doe d/Has a history of memory loss t/mentalIllness t/owesMoney'

Expected output: User added

Actual output: Error non alphanumeric names

Screenshot 2024-04-19 at 5.08.46 PM.png

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

Their Response to the 'Original' Bug

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

In our DG, we mentioned that this is a known issue and we are planning to implement this functionality in future iterations. Hence, we would like to reject this bug.

image.png

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: I must clarify that my bug report, which identifies the restrictiveness of using only names as unique identifiers, is not a duplicate of the other tester's report regarding the character restrictions in names. My issue highlights the potential for multiple individuals sharing the same name, which is common, and the system's need to differentiate them using additional attributes like phone numbers or other identifiers. This is fundamentally different from the character set allowed in names and should be treated as a separate concern.

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** It appears there has been a misunderstanding regarding the nature of the bug reported. My concern was not merely about the characters allowed in names but the use of names as the sole unique identifier within the system, which poses a significant issue in scenarios where multiple individuals share the same name. This is a current limitation that impacts the application's functionality for social workers who require precise and unambiguous client records. As such, I believe that this bug should not be rejected but acknowledged as an important area for improvement in the application's current iteration.
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** The team seems to have misread my report, categorising it as a functionality bug rather than a feature flaw. The essence of the problem is the application's inability to support multiple clients with the same name, which is an expected feature of a client management system. This restrictiveness in identifying individuals uniquely does not align with the realistic conditions under which social workers operate. Hence, it is more aptly classified as a feature flaw, with a "Low" severity level reflecting the potential for some inconvenience and confusion when managing client information.