Team's Response

The suggestion provided is not a bug, but rather a possible improvement that we can look into. The command still achieves the intended effect of ensuring the information for an entity is updated/correct (which is the whole point of the edit command) and therefore fulfils its objective. Hence, this cannot be considered a bug, what's more a medium severity bug. More like a possible improvement.

The 'Original' Bug

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

editing the birth date of the dog with the same date doesn't show an error

No details provided. Screen Recording 2021-04-16 at 2.48.28 PM.mov The initial date of birth of the dog with index 2 is 11-02-2020. But when I input edit dog 2 11-02-2020, there is no error thrown. I think that an error stating the "the input date is already the same as the initial date" should be displayed instead of overriding the date.

_{[original: nus-cs2103-AY2021S2/pe-interim#2693] [original labels: severity.High type.FunctionalityBug]}

Their Response to the 'Original' Bug

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

Definition of a high severity bug:

A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.

Under normal operations, users will not run into such a situation since nobody will edit it to be the same, even under those circumstances, it does not affect the use of the application.

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 severity

Team chose [severity.Low] Originally [severity.Medium]

[x] I disagree

Reason for disagreement: I disagree with the Dev Teams response to both my bug report, as well as the original bug report.

I believe that this bug should have a minimum severity of medium or even high severity as labelled in the original persons bug report.

Firstly, I would like to reference the Dev Teams response to both mine and the original bug report. In particular, "Under normal operations, users will not run into such a situation since nobody will edit it to be the same, even under those circumstances, it does not affect the use of the application.".

Based on what the Dev Team themselves have mentioned, "nobody would have the intention to edit a field to be the same". This is why it is important to catch this as an error and show it to the user when they have indeed made a mistake of trying to update a field with the same unchanged information. The user may have made a minor typo, or a simple misunderstanding of the changes he wanted to make. It is the applications duty to catch such errors, and it is false to assume that the user may not make such mistakes.

Secondly, if the user had made the aforementioned mistake. The app would not have caught it, and considering that this application is built to manage a dog school business. It would lead to devastating effects, where for example the pet class session schedules might be completely misaligned with what the client and the business owner had intended.

Hence I believe that this bug should be of High or at minimum of Medium severity as it would affect most uses and cause major problems for users (mistakes that are costly for the dog school business) further down the line, when the pet school business owner handles many more entries and the likelihood of frequent edits increase, which also increases the likelihood of mistakes made during editing entries or fields.

vevek / pe

Editing an existing entry with the same details does not feedback to the user that the edit did not change anything. #6