search

arnav12344 / pe

0 stars 0 forks source link

Incorrect error message in name format #7

Open arnav12344 opened 1 week ago

arnav12344 commented 1 week ago

image.png

I am listing this as a bug, because of the discrepancy between the error command and the UG. It only says that name can't have ,,@, and / in the UG but it says only alphanumeric in error command

nus-pe-script commented 4 days ago

Team's Response

Thanks for submitting this report.

Comments from dev team: The title of the report is "Incorrect error message in name format" However, from careful reading of the error message, it does seem very correct, you entered non alphanumerics (+ =) and the error message correctly identified it as so and rejected the command. As the name provided contains a /, which is not an alphanumeric character. The command does not execute.

Bug Type that we chose: [nil] The error message has made it clear that not accepting "/" is intended, this is not a functionality bug.

Severity that we chose: Low

Decision that we made: Not In Scope

image.png

Putting in other symbols not mentioned in the UG (eg + = $ # &) is extreme user behavior and is handled by the error message. It is not a bug in any way.

image.png

A suitable error message of "Names should only contain alphanumeric characters and spaces, and should not be blank" was provided.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Thank you for reviewing this bug report. While I understand your explanation that the error message correctly identifies the issue with non-alphanumeric characters, the concern lies in the discrepancy between the user guide (UG) and the application's behavior. The UG specifies that names cannot contain only certain characters such as ,, @, and /, which suggests a more permissive rule than the error message's stricter "alphanumeric only" constraint. This inconsistency can cause confusion for users, especially when names like "Mike O'Leary," which are valid in many contexts, are rejected without clear guidance in the UG. As such, I believe this issue is not a matter of functionality but rather an oversight in documentation or clarity, which could warrant updating either the UG or the error message to align expectations.

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