soc-se-bot
commented
7 months ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
No Warning When Editing Does Not Change Anything
Problem: When user edits a field and the edited field is exactly the same as the original field, a warning should be shown, alerting user that nothing will be changed. However, when I edit a person's phone number to the exact same phone number, the command is accepted and no warning shown. This may cause some inconvenience to the user, as they may not realise they are keying in the same information when editing.
Command:
edit 3 p/93210283Expected: "This is the same as the original phone number." Actual: Command accepted, no warning.Screenshot:
After pressing enter:
[original: nus-cs2103-AY2324S2/pe-interim#4886] [original labels: severity.Low type.FeatureFlaw]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Thanks for bringing this up! When a user performs an Edit command, they intend to replace a certain field's value with a new one, and the application facilitates this intended usage correctly, regardless of the original value.
Similar to a real-world scenario, imagine your boss instructed you to change the date for the meeting minutes to be the current date. As a competent employee, you did it before the instruction was given. You don't argue with your boss, and your boss won't find it inconvenient.
Regarding the statement "This may cause some inconvenience to the user, as they may not realize they are keying in the same information when editing," it's unclear why keying in the same information during editing would cause inconvenience to the user. Therefore, we are unable to address this concern further.
In short, we believe allowing this behavior is more reasonable than disallowing it. For example, when a user wants to perform an edit command on multiple fields, and some fields already have the same information in our records, a reasonable response from the application would be to accept the changes to the fields (even if some fields remain unchanged), instead of blocking the user and asking them to remove fields with identical values from the command.
However, we will consider adding this constraint if deemed necessary.
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 response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.VeryLow`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
How to reproduce: Key in
edit 1 2 3 d/PGPRrepeatedly in the command box.Expected: 2nd edit to be able to detect repeated editing with the same input and then blocking that input with an error message.
Actual: Being able to edit with a success message: Edited person: David Li; Phone: 91031282; Email: lidavid@example.com; Room Number: 21-16-43; Telegram: davidLi; Birthday: 21 April 1998; Dorm Tag: [PGPR]; Free Time Tags: [Tue:0700-2100] Irfan Ibrahim; Phone: 92492021; Email: irfan@example.com; Room Number: 21-17-35; Telegram: irfanIbrahim; Birthday: 16 April 1993; Dorm Tag: [PGPR]; Free Time Tags: [Tue:0700-2100] Palex Yeohss; Phone: 84971422; Email: charlotte@example.com; Room Number: 21-11-04; Telegram: charlotteOliveiro; Birthday: 02 April 2000; Dorm Tag: [PGPR]; Free Time Tags: [Mon:0700-2101][Mon:0000-2359]"