When edit for multiple fields, it allows one field to be the same as the previous

[awc1116]

input:
edit 1 p/91234567 e/Johndoe@example.com

expected:
The inputted edit command does not result in any changes to the specified patient. as phone number is the same

actual:

the email is updated.

when both fields are the same as previous it shows error when one field is same and one is different, it allows it to be edited.

[nus-se-script]

[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

Thank you for raising this issue!

According to our User Guide, we state: If the inputted edit command does not result in any changes to specified patient, it will not be allowed.
This means that as long as at least one field in the command results in a change, the command is valid and will be executed. In the scenario you described, while the phone number remains unchanged, the email field was updated — and therefore, the edit is considered meaningful. Preventing the change when not all the fields in the edit command results in a change could make the command less useful for the user.

As such, this behaviour is intended and consistent with our design specification.

We have marked this issue as NotInScope, as it does not reflect a bug or unexpected behaviour within the defined functionality of the edit command.

Items for the Tester to Verify

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: I disagree with the NotInScope classification, as this issue reflects an inconsistent and confusing edit behavior, not a feature limitation.

According to the team’s interpretation, the edit command succeeds when any field changes, and fails when no changes occur. However, further testing shows:

• edit 1 n/ John Doe → ❌ Rejected

• edit 1 n/ John Doe p/12345678 → ✅ Accepted; and the name was capitalized to John Doe

This shows that the name field was updated, just not accepted unless another field was included. The rejection of the first case contradicts the acceptance of the second — even though both involve the same case change in the name.

This inconsistency affects usability and user confidence in whether changes took effect. It should be considered at least a FeatureFlaw, not NotInScope, especially since this behavior is not clearly warned in the UG.

---