[PM-35357] Update Trial Length Parameter

[sbrown-livefront]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-35357

📔 Objective

This pull request implements a custom trial length to be specified.

API and model changes:

• Added TrialLength (with validation of 0–30 days) properties to organization creation and signup models (OrganizationCreateRequestModel, OrganizationNoPaymentCreateRequest, OrganizationSignup) and ensured these are passed through to business logic and billing.
• Updated the API for sending trial initiation verification emails to require and validate the new fields.

Business logic and billing integration:

• The billing service uses the custom trial length if provided and validated; otherwise, it falls back to the default plan trial period.

📸 Screenshots

Screen.Recording.2026-05-08.at.2.03.17.PM.mov

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This PR adds a customizable TrialLength parameter (0–30 days) to organization signup, threading it from the API request models through OrganizationSignup → OrganizationSale → SubscriptionSetup to Stripe's TrialPeriodDays. Input is defended at the API model ([Range(0, 30)]) and again in CloudOrganizationSignUpCommand.ValidateTrialLength, with a fallback to plan.TrialPeriodDays when no override is supplied. The trial verification email request model is tightened with [Required], [MinLength(1)], and init-only properties, and the hard-coded 7 is extracted to TrialInitiationConstants.DefaultTrialLengthDays. Test coverage is comprehensive across boundary values, null, and the mapping into OrganizationSignup.

Code Review Details

No new findings. All previously raised concerns are resolved:

• Cache miss bypass on trial length validation — resolved (cache removed in 288072d).
• Custom trial length not bound to verified email — confirmed intentional by author; PR description updated.
• Trial-length tests passing for the wrong reason — resolved (thread is outdated against current code).

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.95%. Comparing base (a354aff) to head (411ba18).

Files with missing lines	Patch %	Lines
.../Billing/Models/Mail/TrialInititaionVerifyEmail.cs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7597      +/-   ##
==========================================
+ Coverage   59.84%   59.95%   +0.11%     
==========================================
  Files        2120     2120              
  Lines       93168    93179      +11     
  Branches     8264     8264              
==========================================
+ Hits        55753    55866     +113     
+ Misses      35440    35338     -102     
  Partials     1975     1975              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
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

[cyprain-okeke]

Nice Work!

[cyprain-okeke]

❓ Now that this is just a range check, the [Range(0, 30)] on both request models already covers it for the public API path. Is the duplicate guard here for callers that bypass the model binder (provider signup, internal callers)? If so, fine — if not, we can drop it and let the model attribute be the single source of truth.

[sbrown-livefront]

Yep this is for internal calls that may not run into the model.

[cyprain-okeke]

Nice cleanup