Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI: Email Address #17973

Closed
steveburtch opened this issue Sep 27, 2023 · 7 comments
Closed

UI: Email Address #17973

steveburtch opened this issue Sep 27, 2023 · 7 comments
Assignees
Labels
BTR Business Transparency Register Register BO

Comments

@steveburtch
Copy link

steveburtch commented Sep 27, 2023

Design ticket: UI Design - Email Address (Add a beneficial owner) #17958
Part of epic Add/Register a Beneficial Owner #17846
Wireframes link see UI Design - Add new beneficial owner to company information #15925

Data source: entered free text

Instructions

1. Syntax Validation:
validate email according to RFC (RFC 6532 international)
some examples of the valid:
https://en.wikipedia.org/wiki/Email_address#Examples

2. Length Validation:

  • Overall Length: The entire email address should not exceed 254 characters.
  • Domain Length: The domain name should not exceed 253 characters.
  • Local-part Length: The local-part before the @ symbol should not exceed 64 characters.

3. Presence Validation:

  • Ensure the email field is not left blank if it’s a required field.
  1. Required field

  2. Do not display the field as invalid until an invalid character or invalid sequence of characters is entered

Design ticket: UI Design - Email Address (Add a beneficial owner) #17958

Acceptance Criteria

Feature: Email Field Form Component

Scenario: Populating email field from BCSC
Given the user is on the email input form
When the email field is populated by BCSC with "john.doe@example.com"
Then the email field should display "john.doe@example.com"

Feature: Email Field Syntax Validation

Scenario: Entering email with correct format
Given the user is on the email input form
When the user enters "john.doe@example.com" in the email field
Then the email field should be validated successfully

Scenario: Entering email without "@" symbol
Given the user is on the email input form
When the user enters "johndoexample.com" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email without local-part
Given the user is on the email input form
When the user enters "@example.com" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email with special characters in the local-part
Given the user is on the email input form
When the user enters "john.doe+test@example.com" in the email field
Then the email field should be validated successfully

Scenario: Entering email with consecutive periods in the local-part
Given the user is on the email input form
When the user enters "john..doe@example.com" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email with period as the first or last character in the local-part
Given the user is on the email input form
When the user enters ".john.doe@example.com" or "john.doe.@example.com" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email with domain containing only alphanumeric characters and hyphens
Given the user is on the email input form
When the user enters "john.doe@exam-ple.com" in the email field
Then the email field should be validated successfully

Scenario: Entering email with domain starting or ending with a hyphen
Given the user is on the email input form
When the user enters "john.doe@-example.com" or "john.doe@example-.com" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email with domain containing at least one dot
Given the user is on the email input form
When the user enters "john.doe@example.com" in the email field
Then the email field should be validated successfully

Scenario: Entering email with domain not containing any dot
Given the user is on the email input form
When the user enters "john.doe@examplecom" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email with top-level domain at least two characters long
Given the user is on the email input form
When the user enters "john.doe@example.co" in the email field
Then the email field should be validated successfully

Scenario: Entering email with top-level domain less than two characters long
Given the user is on the email input form
When the user enters "john.doe@example.c" in the email field
Then the user should be notified that the email format is invalid

Scenario: Entering email exceeding max character length
Given the max character length for the email field is 254
And the user is on the email input form
When the user enters an email with 255 characters in the email field
Then the user should be notified that the email is too long

Scenario: Entering email with domain exceeding max character length
Given the max character length for the domain of the email is 253
And the user is on the email input form
When the user enters an email with domain length of 254 characters in the email field
Then the user should be notified that the email domain is too long

Scenario: Entering email with local-part exceeding max character length
Given the max character length for the local-part of the email is 64
And the user is on the email input form
When the user enters an email with local-part length of 65 characters in the email field
Then the user should be notified that the email local-part is too long

Scenario: Entering email with invalid TLD
Given the user is on the email input form
When the user enters "john.doe@domain.a" in the email field
Then the user should be notified that the email TLD is invalid

Scenario: Leaving email field blank
Given the email field is required
And the user is on the email input form
When the user leaves the email field blank and attempts to submit
Then the user should be notified that the email field is required

Scenario: Field appearance with valid email input
Given the user is on the email input form
When the user enters a valid email address
Then the email field should not display as invalid

Scenario: Field appearance with invalid email input
Given the user is on the email input form
When the user enters an invalid character or invalid sequence of characters
Then the email field should display as invalid

@steveburtch
Copy link
Author

@hfekete hfekete self-assigned this Oct 4, 2023
@gunanagar
Copy link
Collaborator

gunanagar commented Oct 16, 2023

Below Scenario failed @hfekete - FYI.

Screen Shot 2023-10-20 at 11 31 05 AM

@gunanagar
Copy link
Collaborator

#18194.

@gunanagar
Copy link
Collaborator

FYI - Below scenario failed @hfekete
Screen Shot 2023-10-20 at 11 38 20 AM

@gunanagar
Copy link
Collaborator

gunanagar commented Oct 20, 2023

  1. FYI - Below scenario failed , pls check @hfekete

Screen Shot 2023-10-20 at 11 40 51 AM

@gunanagar
Copy link
Collaborator

gunanagar commented Oct 20, 2023

FYI - Invalid email address scenario Passed. @hfekete Pls check

i.like.underscores@but_they_are_not_allowed_in_this_part - Invalid email address is not displayed

Screen Shot 2023-10-20 at 11 49 45 AM

@hfekete
Copy link
Collaborator

hfekete commented Oct 24, 2023

Bug ticket opened #18308 for 2 scenarios that do not match RFC according to this wiki

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BTR Business Transparency Register Register BO
Projects
None yet
Development

No branches or pull requests

3 participants