halfwhole / pe

0 stars 0 forks source link

`pat-clear` clears all patients, but not their appointments #6

Open halfwhole opened 5 years ago

halfwhole commented 5 years ago

Since appointments are closely related to their patients, pat-clear should clear not only all patients, but all the appointments associated with patients too (which is all of them). But these are not cleared, leaving the appointments untouched (which doesn't seem right!).

Moreover, when we clear all patients and then try to edit the appointments using say appt-edit 7 desc/new-description, we get this:

The patient index provided is invalid.

[This problem is only observed when deleting patients with pat-clear, but not when deleting patients individually with pat-delete.]

nus-pe-bot commented 5 years ago

Team's Response

I agree that this could have been accounted for, i.e. when pat-clear is executed, all appointments are also cleared.

But do note, however, that this is taken care of for the pat-edit and pat-delete as mentioned in the UG under sections 3.4 and 3.5, i.e. if a patient is deleted, all appointments associated with that patient are also deleted. Similarly for if any of the patient details are edited. If pat-clear affected the appointments in a similar way as pat-delete does, it would have been mentioned in the UG like it was for pat-delete. The fact that it isn't mentioned or highlighted means that this is not accounted for.

Perhaps, I should have mentioned this behaviour more explicitly in the UG. Thanks for having pointed it out. Will work on it in v2.0.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Agree that it isn't explicitly stated in the user guide for pat-clear to remove all appointments. Even so, I'd two reasons for considering it to be an issue:

Given that it can be recovered from though, I'd agree that it should have a reduced severity.


:question: Issue severity

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

Reason for disagreement: [replace this with your reason]


:question: Issue type

Team chose [type.FeatureFlaw]. Originally [type.FunctionalityBug].

Reason for disagreement: Given that it both doesn't work as the user would expect and that it leads to an invalid state (as mentioned above), it should count as a functionality bug.