emptygx / pe

0 stars 0 forks source link

Overzealous input validation #4

Open emptygx opened 1 year ago

emptygx commented 1 year ago

Phone numbers only limited to numerical values, but one might want to input a handphone and office phone for example.

Screenshot 2022-11-11 at 4.32.08 PM.png

nus-pe-script commented 1 year ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Phone Number does not allow country code

There does not seem to be any specification of country of target audience or scope hence it is highly possible some patients have overseas numbers and allowing a country code eg. +65 should be allowed.


[original: nus-cs2103-AY2223S1/pe-interim#3574] [original labels: type.FeatureFlaw severity.Low]

Their Response to the 'Original' Bug

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

We think that it is rare that foreign numbers are used as majority of the appointments in the clinic will be in the clinic itself. Moreover, the user can just add the country code in front of the phone number if it is a foreign number

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)

Reason for disagreement: My report is on the fact that multiple phone numbers are not allowed, such as for the home phone number and handphone number, which is different from the claimed duplicate. Furthermore, the team did not address my concerns.


:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Multiple phone numbers are not allowed per patient, such as for home phone numbers and handphone numbers, which is a common case for clinics that require backup modes of contact, unlike their argument of foreign phone numbers not being common for the other bug.

Even if only numbers are used without the specifiers like (hp), the input validation does not allow multiple phone numbers with a space in between them, which I feel is still overzealous input validation. Hence, this should be a valid feature flaw of low severity.