feat: update send email verification API default parameter for sending email

[sujitaw]

What

• updated the send verification email to be false by default

Summary by CodeRabbit

• New Features
  • Streamlined sign-up for eligible users: when an email is already verified by default, the app skips sending a verification email and marks it as verified automatically, letting users proceed directly to username setup.
  • Conditional verification emails: messages are only sent when needed, reducing delays and inbox noise while keeping the flow secure and consistent.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Walkthrough

Adds an optional isDefaultVerified boolean to request DTO and interface. Updates user service flow: conditionally skip sending verification email when isDefaultVerified is true, immediately verify email post-creation, and proceed with username creation/persistence accordingly.

Changes

Cohort / File(s)	Summary
DTO: user email verification flag apps/api-gateway/src/user/dto/create-user.dto.ts	Adds optional boolean field isDefaultVerified (default false), hidden from Swagger (@ApiHideProperty), validated with @IsOptional and @IsBoolean.
Service: conditional verification flow apps/user/src/user.service.ts	Reads isDefaultVerified from payload; skips email when true; calls verifyEmail after user creation when flagged; adjusts control flow to proceed with username creation/persistence based on flag or sent email.
Interface: payload extension libs/common/src/interfaces/user.interface.ts	Extends ISendVerificationEmail with optional isDefaultVerified?: boolean.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Client
  participant API as API Gateway (DTO)
  participant UserSvc as User Service
  participant Email as Email Service
  participant Verify as Verification Service

  Client->>API: Create user request { email, ..., isDefaultVerified? }
  API->>UserSvc: Validated payload (isDefaultVerified default false)

  alt isDefaultVerified == true
    UserSvc->>Verify: verifyEmail(user)
    Verify-->>UserSvc: verified
    note right of UserSvc: Skip sending verification email
  else isDefaultVerified == false
    UserSvc->>Email: sendVerificationEmail(user)
    Email-->>UserSvc: queued/sent
  end

  UserSvc->>UserSvc: proceed to username creation & persistence
  UserSvc-->>Client: user created (+verified if flagged)

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

Thump-thump goes my coder heart,
A flag flips on—verified at start!
No email hop, no waiting queue,
Just twitchy ears and logic true.
When false, we mail—carrots sent;
When true, we’re stamped—swift consent.
Hop approved. Deployment! 🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.
Title Check	✅ Passed	The pull request title "feat: update send email verification API default parameter for sending email" is related to the actual changes in the changeset. The modifications add an isDefaultVerified optional field that controls whether a verification email is sent (defaults to false, meaning email is sent by default), and updates the email sending logic to be conditional based on this parameter. While the title could be more specific about the new field name and its behavior, it does reference a real aspect of the change and communicates that the default parameter behavior for the email verification API was updated. A teammate reviewing the repository history would understand this relates to email verification API changes, though the title is somewhat broad and could be more descriptive.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/verify-email-modification

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

apps/user/src/user.service.ts (1)

137-137: Initialize the variable for clarity.

The variable sendVerificationMail is declared but not initialized. While the logic works due to short-circuit evaluation on line 169, explicit initialization improves readability and makes the intent clearer.

Apply this diff to initialize the variable:

-      let sendVerificationMail: boolean;
+      let sendVerificationMail: boolean = false;

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 69b8f27 and c61267f.

📒 Files selected for processing (3)

• apps/api-gateway/src/user/dto/create-user.dto.ts (2 hunks)
• apps/user/src/user.service.ts (2 hunks)
• libs/common/src/interfaces/user.interface.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

apps/user/src/user.service.ts (2)

apps/api-gateway/src/authz/authz.service.ts (1)

• sendVerificationMail (44-47)

apps/user/src/user.controller.ts (1)

• sendVerificationMail (58-60)

🔇 Additional comments (6)

libs/common/src/interfaces/user.interface.ts (1)

23-23: LGTM! Interface extension is backward compatible.

The optional isDefaultVerified field is properly typed and maintains backward compatibility with existing code.

apps/api-gateway/src/user/dto/create-user.dto.ts (2)

1-2: LGTM! Import additions are appropriate.

The new imports ApiHideProperty and IsBoolean are necessary for the isDefaultVerified field implementation.

---

42-45: LGTM! Field is properly decorated and validated.

The isDefaultVerified field is correctly configured with:

• @ApiHideProperty() to hide it from Swagger documentation
• @IsOptional() to make it optional
• @IsBoolean() for type validation
• Sensible default value of false

apps/user/src/user.service.ts (3)

116-116: LGTM! Properly extracts the new field.

The destructuring includes the new isDefaultVerified field from the userEmailVerification parameter.

---

153-164: Conditional email sending logic is correct.

The email verification is correctly skipped when isDefaultVerified is true, allowing for immediate verification in the subsequent flow.

---

169-169: No issues: sendEmailForVerification only returns true or throws, so sendVerificationMail || isDefaultVerified covers all edge cases.

[GHkrishna]

As discussed in the CREDEBL call dated 15th October. The fix provided here is not the best way to enable registering users without email verification. As having the flag responsible for making the user verified by default can open path to attacks like spamming of users on CREDEBL.

@sujitaw mentioned he would be revisiting the requirements with @shitrerohit

Some discussed suggestions to implement user registration without email verification were as follows:

• Having a familiar list of pre-approved users known to CREDEBL platform (via. admin access) - This might need having a separate API and table(not sure abut this, will need to check if we can add users to user table without them being registered on Keycloak. I believe we should be able to do this, as the user entry goes to the db without being added to keycloak for email verification)
• Registering unverified users on specific keycloak client. This way the user list is managed by the client owner with their sub-application instead of handling it on CREDEBL. Dependency needs to be checked.

We should be flexible with updating the verification email logic as it is our own, not dependent on Keycloak

CC: @ajile-in @shitrerohit @RinkalBhojani @ankita-p17

[ajile-in]

@sujitaw , @GHkrishna

We can think of:

• Provide an ability to configure client's own SMTP to that there is no dependency on the default SMTP provider i.e. SendGrid
• Provide a way for Platform Admin to manually approve user registrations especially in case where user base is in low numbers (10s) and also in a scenario where userid is used instead of email for user registration.

[GHkrishna]

there is no dependency on the default SMTP provider

I believe the SMTP server would be a complete new feature regarding how someone sends email. For this specific issue I believe we can overlook that(even though a configurable email provider is what we want) for now. Let me know what you think. As this specific issue is mostly to avoid spamming of user accounts without verifying their email(no email required) with the suggested changes

• Provide a way for Platform Admin to manually approve user registrations especially in case where user base is in low numbers (10s)

Yes this was one of the options we discussed, however, as we don't have an admin portal, we can start with an API to add these users for the admin (CREDEBL)

Also, I believe we'll also need to understand the use case for having this and if the base requirement is to add a large number of pre-approved users. This should help us get to the limit/number and if we want that in the first place.

also in a scenario where userid is used instead of email for user registration.

Yess right