app: Able to add students with invalid email

[jiakai-17]

app: Able to add students with invalid email

Affected Component(s)

[x] Application [ ] User Guide [ ] Developer Guide

Description

The email validity check is faulty. I can add a student with email like abc@gmail, which is obviously not a valid email address.

Steps to reproduce

1. Attempt to add a student with invalid email

Command(s) entered:

add n/bad emaild p/91234567 e/fyq@gmail id/A1114569E t/G2

Expected behavior

Invalid email is caught, student not added

Actual behavior

student is added

Screenshots, if any

Additional context / Potentially problematic behavior / Improvements

[x] I have checked that this has not been addressed in the Planned Enhancements of the Developer Guide.

Reason for choosing severity level:

• minor bug, but should alert user at least

[nus-pe-bot]

Team's Response

This issue is a duplicate of #3839 where it states that there is a failure to flag out typos in emails (emails without .com). Therefore, the resolution of this issue will be handled through #3839 where resolution of said issue will also resolve this one.

This is also not a functionality bug as chosen by the tester, as the validity check adheres to our UG.

The 'Original' Bug

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

Fail to flag out typos in emails

Emails does not end with a '.com'

---

_{[original: nus-cs2103-AY2324S1/pe-interim#3005] [original labels: type.FeatureFlaw severity.VeryLow]}

Their Response to the 'Original' Bug

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

According to Google, not every email has to end with a ".com", it just has to end with a valid domain. Furthermore, the domain may be an IP address literal, surrounded by square brackets [], such as jsmith@[192.168.2.1] or jsmith@[IPv6:2001:db8::1], although this is rarely seen except in email spam. Therefore, there are many examples of a domain of an email without a ".com" and it may be incorrect to generalize a valid email as one with a ".com".

Other sources on user@abc being valid email inputs: HTML Standard.

Rejecting user@abc inputs is overzealous, as they are valid emails, although rare. We deliberately adopted a more relaxed validation check for email, with the validation check fully documented in the UG.

Therefore, we decided to reject this bug report as it is theoretically incorrect, as explained above.

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)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** Thank you for your response. I agree that the HTML standard being used widely accepts such email addresses. However, the Internet Corporation for Assigned Names and Numbers (ICANN) has published [an announcement in 2013](https://www.icann.org/en/announcements/details/new-gtld-dotless-domain-names-prohibited-30-8-2013-en) that "dotless domain names" (such as `http://example` and `mail@example`) are prohibited. Hence, it extremely unlikely today (10 years from then) that anyone is using email addresses with these "dotless domains". Moreover, your application and User Guide does not support the sample email addresses with a IP address literal surrounded by square brackets (e.g. `jsmith@[192.168.2.1]`).  

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** This bug is about the email validation logic, which is not a cosmetic issue. According to the [course website](https://nus-cs2103-ay2324s1.github.io/website/admin/tp-pe.html#e-bug-report-format), only cosmetic issues can have the severity.VeryLow tag. 

---