Overzealous input blocking (phone number)

[NeoHW]

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

[soc-se-bot]

Team's Response

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 'Original' Bug

[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]}

Their Response to the 'Original' Bug

[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)

• [x] I disagree

Reason for disagreement:

1. Email and phone numbers are different parameters
2. Allowing multiple additions of email does not automatically allow multiple additions of phone numbers since they are of different fields and parameters.

---

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:**  In the screenshot from CS2103 website, > While your software allows only one phone number in input values, a user might want to input 1234 5678 (HP) 1111-3333 (Office) -- blocking that input might not add any value but allowing it does. This is exactly the example given on the website. > 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: As stated, it would be better to warn than to block as the flexibility allows the user to use the software in different ways while overzealous rejection only serves to annoy the user. > Lack of proper handling (either blocking or warning) for potentially invalid inputs can be considered a type.FeatureFlaw bug too. In this case, this would be a lack of proper handling due to blocking which is considered a FeatureFlaw

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only. severity.Medium : A flaw that causes occasional inconvenience to some users, but they can continue to use the product. In this case, almost the whole population would have more than 1 phone number. This would come in the form of personal phone number and a house phone number(landline). Working adults would even have office phone numbers or work specific personal phone numbers. Therefore, this bug does not "only appear in rare situations and cause a minor inconvenience" as almost everyone has more than one phone number. Users who can only put in one phone number can continue to use the product, but would cause occasional inconvenience as overzealous rejection of inputs can annoy the user.

---