[PM-41951] sponsored families email template copy

[JaredScar]

🎟️ Tracking

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

📔 Objective

Fixes email copy for new terminology directed by Design.

📸 Screenshots

[github-actions]

ℹ️ Limited Platform familiarity

This PR touches a platform-community area. The Platform team owns this code but does not actively develop it, so a Platform review here may be less authoritative than usual.

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Copy-only change to the four Families-for-Enterprise sponsorship offer templates plus the offer email subject in HandlebarsMailService. No behavioral, data, or security-relevant logic changed; {{SponsorOrgName}} remains HTML-escaped (double braces) in both HTML templates, {{{Url}}} interpolation is unchanged, and no test asserts the previous subject string. The later commits resolved the earlier terminology mismatch — all four templates now consistently use "plan".

Code Review Details

• ❓ : New-account copy drops the "this email address" constraint, but redemption requires the registered account email to match the invited email exactly (already raised inline, thread still open)
  • src/Core/MailTemplates/Handlebars/FamiliesForEnterprise/FamiliesForEnterpriseOfferNewAccount.html.hbs:5 (and .text.hbs:2)

Also noted, not posted inline: the new subject Accept your Sponsored Families Plan keeps title case on "Sponsored Families Plan" while the button copy moved to sentence case ("Accept offer", "Create account") — worth a quick check against the Design copy deck.

[claude]

❓ QUESTION: New copy drops the "this email address" constraint, but redemption requires the account email to match the invited email exactly.

Details

Previous copy: "you will need to create an account with this email address". New copy: "create a Bitwarden account with your personal email address".

OrganizationSponsorshipOfferTokenable.IsValid (src/Core/Models/Business/Tokenables/OrganizationSponsorshipOfferTokenable.cs:50-57) requires Email.Equals(currentUserEmail, ...) — if the recipient registers with a different personal address, RedeemSponsorship fails with Failed to parse sponsorship token.

The offer link does carry &email={{SponsoredEmail}}&register=true, so the happy path prefills the correct address. But if the register form allows editing that field, the new wording invites a mismatch that surfaces as an opaque token error.

Was this constraint considered with Design? Something like "create a Bitwarden account with this email address" preserves the requirement while keeping the new tone. Same wording in FamiliesForEnterpriseOfferNewAccount.text.hbs:2.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.26%. Comparing base (5358a2f) to head (1c1f886).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##           main    #8217       +/-   ##
=========================================
+ Coverage      0   63.26%   +63.26%     
=========================================
  Files         0     2381     +2381     
  Lines         0   103902   +103902     
  Branches      0     9405     +9405     
=========================================
+ Hits          0    65736    +65736     
- Misses        0    35916    +35916     
- Partials      0     2250     +2250     

☔ View full report in Codecov by Harness.
📢 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.