search

Zack-Tay / pe

0 stars 0 forks source link

Email able to accept non-email type format #2

Open Zack-Tay opened 2 months ago

Zack-Tay commented 2 months ago

Steps to reproduce

typing: add n/John Doe p/98765432 e/johnd@132 a/John street, block 123, #01-01

Expected

Since this is not a conventional email format, the app should throw an error.

Actual

But the app accepts such value, which means an invalid value for email is accepted.

Screenshots

emailBug1.png

emailBug2.png

soc-pe-bot commented 2 months ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Application accepts bad email

Description

The application accepts bad emails such as 'example@com' which should not be the case since such emails are invalid.

image.png

Steps to reproduce

  1. Input the command add n/Xavier Tan p/98765432 e/xavt@mail a/Ang Mo Kio street 2, Block 123, #01-01 (Notice how the email inputted here is an invalid one).
  2. Hit 'Enter'.
  3. Contact is added to the system.

Expected Behaviour

Application should show an error to input a correct email.

Actual

System still inputs the new contact.

[original: nus-cs2103-AY2324S2/pe-interim#653] [original labels: type.FeatureFlaw severity.VeryLow]

Their Response to the 'Original' Bug

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

We understand your concern, but we will have to reject this bug as xavt@mail is indeed a valid email. This is based on the standard email name conventions which states that the domain (the part after @) can be a local domain name without TLD (eg. .com), meaning that emails without a dot are allowed. You can read more here to find out more about this issue.

In terms of the local domain name, there are no restrictions as well as it is determined by the person who created the email. Screenshot 2024-04-22 at 11.11.02.png

You can find more details in the following website on the naming conventions for emails here.

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)

Reason for disagreement: Maybe the group can give some real-world examples of emails where the domain consists of solely numbers.

## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** This is definitely as users who enter "a@123" or "a@gmail" will never be able to be contacted through email.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** This can be said to be a functionality bug as it "differs from normal behaviour" as according to the CS2103T website. In widely used email convention, widely used domain names such as "u.nus.edu.sg", "gmail.com" and more are the norm.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** I disagree as this can certainly cause some degree of inconvenience and annoyance if users were to accidentally enter an incorrect email address accidentally sometimes. Furthermore, it accepts email format with solely numbers in it, a format that is almost never seen in the real world today. Maybe the group can give some real-world examples of emails where the domain consists of solely numbers.