BunnyHoppp / pe

0 stars 0 forks source link

Email Format #3

Open BunnyHoppp opened 1 week ago

BunnyHoppp commented 1 week ago

Expected: DOMAIN must be at least 2 characters long and start and end with alphanumeric characters.

image.png

Actual: DOMAIN does not accept a.a, which is 3 characters long and starts and end with alphanumeric characters in accordance with the expectation.

Steps to reproduce:

  1. List (provided the list is not empty)
  2. edit 1 e/test@a.a

image.png

Low severity since the email domain is usually not a.a or similar.

soc-pe-bot commented 3 days ago

Team's Response

The email test@a.a fails validation because the DOMAIN rule in the UG requires it to be at least 2 characters long and start and end with alphanumeric characters. While a.a is 3 characters overall, the top level domain(TLDs), the "a" after "." is only 1 character, violating the intended interpretation of the rule. This behaviour aligns with the UG and practical email validation standards, which assume TLDs are at least 2 characters long. In summary "a.a" is by default an invalid email structure to begin with, and will not be accepted in the system.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: When reading the UG, the format given is LOCAL-PART@DOMAIN, as a user, I am not familiar with the technicalities of domain having a top level domain (TLD) and it was not stated clearly in the UG. I would expect that the entire DOMAIN accepted a.a after reading the UG. I feel that this is a valid functionality bug and should not be rejected, because an input of a@a.a is possible as a dummy value to meet the validity of the email as per the UG in the case where the user does not know the email of the patient. Furthermore, the UG is not clear about the limitations of the email, hence there is a functionality flaw in terms of what email is accepted by NovaCare. Furthermore, it would not have taken much effort to clarify further the limitations of email (with regards to the different levels of the domain i.e. top level domain).


## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Low`] - [x] I disagree **Reason for disagreement:** When reading the UG, the format given is `LOCAL-PART@DOMAIN`, as a user, I am not familiar with the technicalities of domain having a top level domain (TLD) and it was not stated clearly in the UG. I would expect that the entire DOMAIN accepted `a.a` after reading the UG. I agree that `a.a` is not a real email domain and that it would not really be used, hence I feel that the severity is low. But I think that this bug is not purely cosmetic as it affected the functionality even in minimal ways. Furthermore, if the user does not know the patient's email and would like to add a dummy email with the minimal characters to be considered a valid email, the user might attempt to input such an input (`a@a.a`) as the email.