email format issue

[yapjoonsiong]

Email in the wrong format but the error message does not accurately explain the problem with the format. I deduced it to be due to a missing period '.' symbol. This is neither explained in the error message nor the UG.

upon further inspection, this bug was due to missing suffixes that is not explained in the error message nor the UG. (ie. missing '.com' or '.sg. suffixes)

[nus-pe-script]

Team's Response

No details provided by team.

The 'Original' Bug

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

Email formatting error

My input does not break any of the established rules but it is not accepted.

---

_{[original: nus-cs2113-AY2122S1/pe-interim#2388] [original labels: severity.Low type.FunctionalityBug]}

Their Response to the 'Original' Bug

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

The email address input is an incorrect email id and won't be accepted on an email client. There are many such corner cases and the rules for email validation are quite strict and it does not make sense from a user experience perspective to list all these uncommon rules as it will only confuse users further. Some of the rules are listed here.

If an email can be created, our app should accept it as it is meant for real-world usage.

Items for the Tester to Verify

❓ Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: While I understand there are many corner cases that are difficult to account for, if you have designed the program to only accept a limited set of TLD for the domain, this should have been documented since it's a small set anyway. Take for example a normal school email being input as contact information here, its rejection without explanation would lead to confusion. Another way to solve this is to not set any limitations in the first place since your team already acknowledges there are too many edge cases to account for. For these reasons, I dont think this bug should be rejected

---

❓ Issue type

Team chose [type.FunctionalityBug]
Originally [type.FeatureFlaw]

• I disagree

Reason for disagreement: [replace this with your explanation]

---