Duplicate exact same appointment notes

[lynnetteeee]

Description Set the context.

In the UG, it is stated that duplicate timings are allowed, and that is reasonable. However, I tried inputting the exact same date, time and exact same word-for-word note, and the entry went through.

Steps to reproduce

1. Launch the application for the first time to load initial data.
2. Run add-an 1 d/19-02-2024 t/1130 n/General Flu
3. Run add-an 1 d/19-02-2024 t/1130 n/General Flu

Expected behaviour

Error or warning message indicating an exact same appointment note has been added before, and the new entry is a duplicate.

Actual behaviour

The new entry went through, and there is now 2 exact same appointment note as seen in 3 and 4.

Reason for severity

This may hinder the usage of your app, making it inconvenient if doctors accidentally input the same notes twice but are not warned or blocked, and end up having to go back to delete it again. This validation for adding appointment notes could be implemented in the better way from the perspective of the end-user (doctors), with possibly a simple check in all the field. Thus it is a feature flaw. However, it does not cause any detrimental problem, just inconvenience, thus it is of Low severity.

Ideas

This may be solved with an additional equality check in the fields.

[nus-pe-script]

Team's Response

We disagree that this is a feature flaw. In order for the doctor to enter a duplicate record, he has to do the following:

1. Type add-an 1 d/19-02-2024 t/1130 n/General Flu
2. Press enter -> system clears text input
3. Type add-an 1 d/19-02-2024 t/1130 n/General Flu
4. Press enter

That is a lot of keystrokes and absolutely has to be intentional. It's also worth noting that the information is immediately updated on screen. For those reasons, it's unlikely that the doctor would add a duplicate record.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Hi, after all, as per the guidelines of the course website, it is still a feature flaw, pertaining to duplicate detection (in the context of appointments).

The thing is, yes, while entering the duplicate record immediately is likely intentional as your team mentioned, we can't rule out the possibility of a doctor forgetting that he has keys in a record after some time (non-immediate).

Example: Today is a very hectic day, clinic packed since opening, and as much as he wishes to be systematic, some patients he has time to key in some he doesn't, then at the end of the hectic day OR the next day, he forgot that he already keyed in the follow-up appointment date for this patient, and ends up keying in a duplicate but was not prompted.

As such, I'd judge that this is still a feature flaw, but tying in with the severity I put, I'd say its of Low severity!

---

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** As per the course guidelines, VeryLow needs to be a cosmetic issue. I indicated this bug as Low, since it is not cosmetic, and it is unlikely to affect the normal operations of your app but the inconvenience cannot be totally ruled out, and is possible to hinder the doctors who have hundreds of patients to keep track of (as seen in the research below, in a localised context) and is unlikely to remember whether they've keyed in an appointment for all the patients they have, as explained above too. To delete the duplicate record brings the doctors minor inconvenience, hence I indicated this as Low and not Medium.  

---