The ADD feature does not account for special email formats

[yleeyilin]

Steps to reproduce:

• As per the UG, I have inputted add ic/S9974944F n/John Toe p/91234567 e/I❤️CHOCOLATE🍫@example.com g/M b/11-11-1990 d/Paracetamol | Penicillin i/Infectious Diseases, which does not accept the current email format.

Expected:

• I expected to get a new patient to be added.

Actual:

• However, I got an error message instead.

Screenshots:

While this is good effort on validation, according to wikipedia on email formats, this is still a valid email format and is considered as a feature flaw especially if patients only have such special emails.

[soc-se-bot]

Team's Response

Duplicate of #2992

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Email address following the UG specified format rejected by the app

add ic/S9974944F n/John Doe p/91234567 e/john.-doe@email.com g/M b/11-11-1990 d/Paracetamol | Penicillin i/Infectious Diseases

---

_{[original: nus-cs2103-AY2324S2/pe-interim#3764] [original labels: type.FunctionalityBug severity.Low]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

This is indeed a bug as specified by the UG as well it should be a valid email:

Hence, Accepted

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: The bug that I caught was behaving as expected in the user guide, which is different from the bug that the duplicate issue caught.

In the bug that I caught, I included special characters even though the user guide mentioned that special characters are not allowed. However, I reported this bug since it is a valid email format, as seen in the link I included, implying that the feature design of email validation is flawed.

In the "duplicate bug" report, the command tests the validations within the confines of the user guide which is different from mine and should not be considered a duplicate bug.

---

## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** The bug that I caught was behaving as expected in the user guide, which is different from the bug that the duplicate issue caught. In the bug that I caught, I included special characters even though the user guide mentioned that special characters are not allowed. However, I reported this bug since it is a valid email format, as seen in the link I included, implying that the feature design of email validation is flawed. Since what I inputted was not an unexpected behaviour, but a valid behaviour that is not as user friendly, it should be considered a feature flaw, not a functionality bug.

---