Unable to edit patient name to upper case

[awc1116]

input:
edit 10 n/Shamugan

expected:
I had a patient name shamugan and when added I did not make the first letter to upper case when I do the command it should update the name to Shmugan however i can change the case for email.

edit 1 e/Johnd@example.com

actual:
"The inputted edit command does not result in any changes to the specified patient."

[soc-pe-bot]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Hello! Thank you for your feedback :D

After much consideration, we have decided to assign this as not in scope as we have clarified in the user guide that duplicate names are not allowed (case-insensitive). This implies that users are not allowed to edit any patient's name to an exisiting patient's name in the list regardless of upper case or lower case.

Let us illustrate this with an example.

For instance, I have a patient called shamugan in my patient list. I am not allowed to edit his name or other patients' names to Shamugan. This is because we clarified in the user guide, under input requirements that duplicate names are.not allowed (case sensitive).

Fun fact: We implemented this feature to protect users from accidentally inputting 2 names that are have the same letters, just different casing. When users try that, we give a warning, instead of an error, to the user that the inputs for their edit command actually does not change any of the patient's details. This encourages the user to name duplicate patient names in a different way (e.g. shamugan_west and shamugan_east) and prevents them from getting confused when they see 2 patients with the same name in their patient list.

In this light, this warning given does not allude to a functionalitybug since it works as specified and curated by us for our social workers (users)

Also, this feature is not too important, since the user can easily tell for example that "john Doe" is the same person as "John Doe", and trying to fix it would take away time from implementing more important features.

Hope this clarified :)

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: I disagree with the NotInScope classification. While I understand that the UG states names are treated case-insensitively and disallows duplicates, the issue here is not about requesting a new feature — it's about inconsistent behavior of the edit command.

Specifically:

• When I run edit 1 n/John Doe, the command is rejected.

• But when I run edit 1 n/John Doe p/12345678, the command is accepted and updates the name casing to John Doe, even though it already existed in lowercase.

This means that the app does allow case updates to names, but only when another field is changed too — which contradicts the claim that the app prevents duplicate names (regardless of case).

This is confusing for the user, especially if the goal is to correct a lowercase name to a proper noun. According to PE guidelines, this is not NotInScope — it's a FeatureFlaw, as it results in inconsistent edit logic and poor user feedback.

---