search

KSSWSept20 / pe

0 stars 0 forks source link

Inaccurate command message for usage of "d/o" #5

Open KSSWSept20 opened 5 months ago

KSSWSept20 commented 5 months ago

image.png

Regarding to the constraint on name field, the error message when "d/o" is input in the name field should be similar to when other symbols are used: Names should only contain english alphanumeric characters or spaces, should not be blank and must contain less than 55 characters

Instead, it shows: Invalid command format!

nus-se-script commented 4 months ago

Team's Response

Hello, thank you for raising this issue.

In this case, d/ is a known prefix in CLInic for appointment date and is taken to be an erroneous prefix that should not be in the addPatient command, and hence, the invalid command error.

If we were to have given a name constraint error for this case, then the contrary bug would arise - where n/ Alisya d/2024-02-02 will give the name constraint error which is arguably inaccurate as well.

However, it should also be noted that that inclusion of compatibility with such names is in the planned enhancements section of our DG. Any further implementation to account for these symbols should be subsumed under this.

image.png

Therefore, on these accounts, this is the expected behaviour for now, until the planned enhancements have been implemented.

Response rejected.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: "If we were to have given a name constraint error for this case, then the contrary bug would arise - where n/ Alisya d/2024-02-02 will give the name constraint error which is arguably inaccurate as well."

For this line of reason given by the dev team, it should be an implementation issue on the developer side instead of the user's fault. In fact, the result now is indeed showing the inaccurate error message to the user. It should be the developer's responsibility to fix the error message instead of justifying it by saying that the implementation is hard. Even if it is justifiable, this reason is still not written in the UG or DG.

"If we were to have given a name constraint error for this case, then the contrary bug would arise - where n/ Alisya d/2024-02-02 will give the name constraint error which is arguably inaccurate as well." As for this, I do not think that this planned enhancement is related to the wrong message shown. It is addressing the availability of symbols as an input to the name field instead of proposing to change the error message to be more specific or accurate.