Overzealous inputs not allowed

[gnoossk]

Issue Name

Overzealous inputs not allowed

To Reproduce

1. add n/John Doe c/ABC Inc p/12345 p/23451 e/John@gmail.com a/seasme street

Expected behavior

• Multiple Phone numbers assigned to John Doe

Severity

• Medium - The case of clients having more than one phone number is quite common, so this feature flaw can limit users

Reference – cs2103 bug severity levels

Screenshots

[soc-pe-bot]

Team's Response

As a developer

It's stated that p/ is a single-valued field, and attempting to bypass that would result in error but doesn't crash the software.

Furthermore, supporting more than 1 phone number for a client would've required a similar restructuring/refactoring of the phone field to behave akin to transactions/tags, "i.e., the supposedly 'better' implementation will take more effort than the current implementation, reducing the effort available to spend on other more important tasks", namely supporting more relevant, transaction-related commands for our financial consultants, instead of just having an extra phone number.

From the user perspective

Even more so, we already allowed great flexibility in the phone number formatting: we allow unlimited length in phone numbers, support single spacing, and even a free text field for [Notes]. Users have many options as to how they can utilise these flexibilities to incorporate into their workflows. If they're dealing with clients who, for some reason, all unanimously have a lot of phones (and the user must, for some reason, remember every single one of these alternate phone numbers), they have many options:

p/12345678 [987654321] adds the phone 12345678 and also the note [987654321] as a second phone p/12345678 98765432 88889999 [hp-hq-land] stores the entire string as shown, and can be interpreted accordingly as 3 phone numbers, with a note to explain what purpose each number serves.

Better yet, each of those command requires less work than having 2-3 separate p/ delimiters. We believe our current implementation offers even greater flexibility than the alternative suggestion.

Severity

We believe a High is completely unjustified "makes the product almost unusable for most users". At worst, this is an issue that affects a mysterious minority of users with clients whose phone numbers are so special they cannot be made sense of even with unlimited string length and single spacing and an extra free text field for [Notes].

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---