Email prefix accepts invalid top level domain in email address

[AdityaB4]

Steps to reproduce:

• Use this command add n/Invalid TLD Mail Doe p/98765432 i/0 e/johnd@example.techno a/311, Clementi Ave 2, #02-25 f/4 t/buyer t/seller h/HDB r/Has 3 cats b/01May2009
• The client gets added with the non existent top level domain "techno"

Potential scenarios:

• In regular use, while typing out the long add command, a real estate professional could accidentally make a typo in the top level domain. Without any prompt about this, the user could possibly loose the client's actual email.
• The above scenario would be more than just a minor inconvenience, since it reflects poorly on the real estate professional to ask for a client's email multiple times.

[soc-pe-bot]

Team's Response

There is no reason for us to implement overzealous input validation. Allowing such flexibility can in turn allow the user to use the software in their own preference while overzealous rejection of inputs can annoy the user.

https://nus-cs2103-ay2324s2.github.io/website/admin/tp-pe.html#feature-flaws-2

This is not a functionality bug as our EMAIL works as intended by accepting all TLDs.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I believe the section about overzealous input validation being cited here has been misinterpreted. The point for not having overzealous input validation is to allow for valid and sensible inputs to be represented in different ways. Example from the CS2103T website: phone numbers allowing brackets so that users can enter something along the lines of (H) <phone number> where <phone number> is any valid phone number.

However, in this case, allowing for an input that is not a valid or sensible email, i.e., some text that has an invalid TLD (like .techno) would be considered a bug. To add on to this, allowing for an invalid email input could cause loss of valuable information as mentioned in the original issue description.

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** I disagree since this fits under the definition of a functionality bug: "A functionality does not work as specified/**expected**.", as it does not work as one would **expect** an email input to work. Especially since these exist in many apps that are used regularly nowadays, creating a strong expectation from, or familiarity to an email input.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I disagree since this reasonably fits under the definition of a Medium bug: > severity.Medium : A flaw that causes occasional inconvenience to some users, but they can continue to use the product. Entering an invalid TLD would cause occasional inconvenience to some users, but they can continue to use the product by asking their client for the valid email again.

---