Open NeoHW opened 4 months ago
The above scenario is not an instance of overzealous input. The user is trying to use two of the same parameters in one command, which is a different issue from overzealous input.
The error message shown is an accurate description of the issue (using 2 of the same parameters in 1 command). Moreover, in the UG it is stated that phone no. parameter is only single-valued and the client cannot have multiple emails. Therefore, we would like to reject this issue.
Additionally, we recommend the severity to be decreased from Medium to Low as the issue only causes minor inconvenience.
[The team marked this bug as a duplicate of the following bug]
Overzealous input blocking (email)
steps to reproduce:
add n/test test t p/112 e/test@gmail.com e/testschool@gmail.com t/Pneumonoultramicroscopicsilico
Overzealous input blocking for allowing only one email, which does not add any value but allowing it does.
Suggestion: It is better to warn rather than to block when inputs are not compliant with the expected format, unless accepting such inputs can hinder the operations of the software. Allowing such flexibility can in turn allow the user to use the software in ways you didn't even anticipate while overzealous rejection of inputs can annoy the user!
For example: A user might want to input test@gmail.com (personal) testschool@gmail.com (school) -- blocking that input might not add any value but allowing it does.
[original: nus-cs2103-AY2324S2/pe-interim#858] [original labels: severity.Medium type.FeatureFlaw]
[This is the team's response to the above 'original' bug]
The above scenario is not an instance of overzealous input. The user is trying to use two of the same parameters in one command, which is a different issue from overzealous input.
The error message shown is an accurate description of the issue (using 2 of the same parameters in 1 command). Moreover, in the UG it is stated that email parameter is only single-valued and the client cannot have multiple emails. Therefore, we would like to reject this issue.
Additionally, we recommend the severity to be decreased from Medium to Low as the issue only causes minor inconvenience.
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:
Overzealous input blocking for allowing only one phone number, which does not add any value but allowing it does. Suggestion:
It is better to warn rather than to block when inputs are not compliant with the expected format, unless accepting such inputs can hinder the operations of the software. Allowing such flexibility can in turn allow the user to use the software in ways you didn't even anticipate while overzealous rejection of inputs can annoy the user!
For example: A user might want to input 1234 5678 (HP) 1111-3333 (Office) -- blocking that input might not add any value but allowing it does.
steps to reproduce:
add n/test test t p/112 p/1122 e/test@test t/Pneumonoultramicroscopicsilico