gerteck / pe

0 stars 0 forks source link

editc behavior not specified and differ from normal expectation #5

Open gerteck opened 5 months ago

gerteck commented 5 months ago

When I try to editc of a patient that does not have any existing contact field, (no email, phone, address), it throws an error:

image.png

Step to reproduce is:

  1. Start with sample data
  2. editc ic/G7654321L p/98765432

Issue is that UG does not specify that it must have existing contact info, and it is said that: editc is "Edits the contact information of a patient in the clinic. It is also used to add or delete certain fields of the contact information"

The expectation would be then to be able to use editc to add information for new patient, however it throws a misleading error saying that contact info not found, which is a wrong statement.

Causes occasional inconvenience, however, can continue to use since using addc first will work. However, user must know this specific trick.

nus-pe-bot commented 5 months ago

Team's Response

Thank you for pointing that out. But this attempt at the beginning “When I try to editc of a patient that does not have any existing contact field, (no email, phone, address), it throws an error” is a misunderstanding of our editc command.

As shown in the screenshot, we have explained very clearly that one needs to "add" the contact/medical information. If there is no need to use the information, there is also no need to add information. According to this part of the explanation, our system adopts a modular way of saving data. Therefore, one needs to first "add" contact/medical information before being able to edit it. And the "edit" action is mainly for adding or deleting fields when the respective information already exists. image.png

Moreover, in the section of "edic" command, it is clearly stated that: "If all three fields of contact information become empty, the contact information of the patient will be deleted. To add a new contact information, use the addc command." This sentence tells that when all three fields are empty, the contact information is considered deleted, and one should not use "editc" and should use "addc" instead. image.png

The above two pieces of information in the UG would be sufficient for users to understand the mechanism of addc and editc. Therefore, the behavior mentioned by the tester for editc is reasonable and not a functionality bug. In the worst case, users might argue that the usage of phrases like "become" and "will be" sounds kind of ambiguous. In this case, it would be a documentation bug with severity VeryLow because it doesn't affect any usage of the product and one could indeed understand the whole logic by reading the UG carefully. We totally understand that since there is a time constraint pressure during the PE, it is very common to neglect points in the UG.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: [replace this with your explanation]


## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]