search

Kureans / pe

0 stars 0 forks source link

No Exception Handling for invalid/inaccurate ID #2

Open Kureans opened 2 years ago

Kureans commented 2 years ago

Description: Although there was no explicit mention of a certain format needed for the CLIENT_ID input, all the example inputs given involved something like "cxxx" where x are integers, so I think there could be exception handling for CLIENT_ID inputs that do not match the format, and not just accept any non-empty string.

Steps to reproduce: add -c -a /n jondd /cn 00000000 /m something@eg.com (add any non-empty input for CLIENT_ID param)

Expected: Some kind of error message that says input should follow "cXXX"

Actual: image.png

soc-se-bot commented 2 years ago

Team's Response

We did not specify in the UG what the format of the client ID should look like. This is because different tour agencies might have different formats, and it is up to the user's discretion.

image.png

It was intentional as we wanted to prevent overzealous input validation which is a feature flaw.

Furthermore, the severity should not be labelled as medium as this is a flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I agree that there should not be overzealous input validation, especially for fields where it might actually be useful to keep track of non-standard inputs such as the 2 phone number example given in your SS.

However, I think that there's value in at least specifying a preferred format and giving a warning message when users do not abide by that format for the CLIENT_ID field. This is especially so for the CLIENT_ID field which I believe should be a field that's quite fixed/strict about the format compared to other fields like phone number/address for indexing/sorting purposes. If there were 2 interns that had misunderstandings on how the format was supposed to be written, it could 1. Accidentally allow duplicate entries, and 2. Mess up any CLIENT_ID sorting functionality, if for instance one person put "-CXXX" vs "CXXX".

:question: Issue severity

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

Reason for disagreement: [replace this with your explanation]