[FEAT]: Email Messaging for Account Verification and Magic link Sign-Ins

[Bluel0la]

Acceptance Criteria

Description:

Implement a unified email notification service to handle email notifications for account verification for new users and magic-link sign-ins. This service should manage all email-related functionalities.

Purpose:

To streamline and centralize the email notification process for account verification and magic-link sign-ins, ensuring consistency and ease of maintenance.

Acceptance Criteria:

1. Automated Email Notification System:

   • Design and implement an automated email notification system for registrations and magic link sign-ins.
   • The system should handle different types of email notifications (e.g., account verification, magic-link sign-ins).

2. User Preferences:

   • Allow users to enable/disable specific email notifications.
   • Store email notification preferences securely in the database.

3. Email Delivery:

   • Display appropriate messages for successful email delivery.
   • Handle and retry failed email deliveries.

4. Email Templates:

   • Implement email templates for user notifications.
   • Templates should include placeholders for dynamic content such as user name and verification/magic links.

Expected Outcome:

• The system should send email notifications containing verification links and magic links in a timely manner for registration and sign-in, respectively.

Requirements:

• Develop an interface for managing email notification settings.
• Implement server-side logic for sending emails.
• Validate and handle email notification requests.
• Securely store email notification preferences in the database.
• Implement email templates for user notifications.
• Provide user feedback on successful/failed email actions.

Endpoints:

User Registration:

Description: Register a new user and send an account verification email.

USER REGISTRATION [POST] /api/v1/auth/register

{
  "firstName": "String",
  "lastName": "String",
  "email": "String",
  "password": "String",
  "confirmPassword": "String"
}

Response (Success)

{
  "message": "Registration successful. Please check your email for verification link.",
  "user": {
    "id": "String",
    "email": "String"
  }
}

Response (Error)

{
  "message": "Email already exists",
  "statusCode": 400
}

Magic Link Sign-In:

Description: Send a magic link email for user sign-in.

MAGIC-LINK SIGN-IN [POST] /api/v1/auth/magic-link

{
  "email": "String"
}

Response (Success)

{
  "message": "Magic link sent successfully. Please check your email."
}

Response (ERROR)

{
  "message": "Failed to send magic link",
  "statusCode": 400
}

Testing:

• Write unit tests for server-side email handling.
• Test various scenarios for email delivery (e.g., successful, failed, retry).
• Test the end-to-end flow from user registration to email verification.
• Ensure the email notification system works as expected for both new registrations and magic link sign-ins.

Example Email Templates:

Account Verification Email:

Subject: Verify Your Account

Body: Click the link below to verify your account:

   [Verification Link]

Magic Link Email:

Subject: Sign In with Magic Link

Body: Click the link below to sign in:

   [Magic Link]

Corresponding database Tables for the implementation of the endpoints:

Table User {
  user_id integer [pk, increment]
  first_name varchar(100) [not null]
  last_name varchar(100) [not null]
  email varchar(255) [unique, not null]
  password varchar(255) [not null]
  created_at timestamp [default: 'now()']
  updated_at timestamp [default: 'now()']
}

Table EmailTemplate {
  template_id integer [pk, increment]
  name varchar(100) [unique, not null]
  subject varchar(255) [not null]
  body text [not null]
  created_at timestamp [default: 'now()']
  updated_at timestamp [default: 'now()']
}

Table EmailLog {
  email_log_id integer [pk, increment]
  user_id integer [not null, ref: > User.user_id]
  template_id integer [not null, ref: > EmailTemplate.template_id]
  status varchar(50) [not null]
  sent_at timestamp [default: 'now()']
}

Table EmailPreferences {
  preference_id integer [pk, increment]
  user_id integer [not null, ref: > User.user_id]
  email_notifications_enabled boolean [default: true, not null]
  created_at timestamp [default: 'now()']
  updated_at timestamp [default: 'now()']
}

Table EmailVerification {
  verification_id integer [pk, increment]
  user_id integer [not null, ref: > User.user_id]
  token varchar(255) [unique, not null]
  type varchar(50) [not null] // e.g., 'account_verification', 'magic_link'
  is_used boolean [default: false, not null]
  created_at timestamp [default: 'now()']
  expires_at timestamp [not null]
}

[markessien]

Emails should be integrated into one service

[Bluel0la]

On it Sir

[pesova]

Your APIs must be versioned. You must at all times follow REST API naming conventions and best practices; please study the included resources REST API naming conventions API Best practices

[Bluel0la]

@markessien done please can you review

[Bluel0la]

@pesova it has been implented