[PM-16095] Fix up messages for Teams error messages for seat counts

[JaredScar]

🎟️ Tracking

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

📔 Objective

Terminology fixes for error messages for seat validation error messages

📸 Screenshots

Can manage billing (Teams):

Cannot manage billing (Teams):

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the seat-limit error message changes across the legacy OrganizationService.InviteUsersAsync path and the newer InviteUsersPasswordManagerValidator path, plus the two error records, the new CanManageBilling flag, and their tests. Earlier feedback is resolved: both messages format MaxAutoScaleSeats rather than Seats, CanScaleAsync keeps the flow-neutral SeatLimitHasBeenReachedMessage for restore, Families sponsorship and JIT provisioning, the invite-only substitution is isolated in ToInviteSeatLimitMessageAsync, and canManageBilling now rides on PasswordManagerSubscriptionUpdate instead of being threaded through the Core validators. organization.MaxAutoscaleSeats!.Value and string.Format(Code, MaxAutoScaleSeats) are each only reachable from branches that already require HasValue, the provider-specific messages fall through the exact-string comparison untouched, and CanManageBillingAsync short-circuits on UserId.HasValue so SCIM and Public API callers cannot NRE inside GetOrganizationProviderDetails. The invite-link confirm path discards the message in favour of ConfirmOrganizationHasNoAvailableSeats, so the canManageBilling default of false there has no user-visible effect, and the new tests set Seats and MaxAutoscaleSeats apart so they pin which number is reported.

Code Review Details

• ❓ : Members-grid "Send invite" action (staged users) is a second invite entry point that keeps the old neutral wording — open thread, no new comment posted
  • src/Core/AdminConsole/Services/Implementations/OrganizationService.cs:874

[codecov]

Codecov Report

❌ Patch coverage is 86.20690% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.64%. Comparing base (51aba60) to head (21a4d39).

Files with missing lines	Patch %	Lines
...le/Services/Implementations/OrganizationService.cs	75.00%	2 Missing and 1 partial ⚠️
...s/InviteUsers/Validation/PasswordManager/Errors.cs	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8406   +/-   ##
=======================================
  Coverage   64.64%   64.64%           
=======================================
  Files        2482     2482           
  Lines      106388   106409   +21     
  Branches     9666     9670    +4     
=======================================
+ Hits        68774    68791   +17     
- Misses      35272    35275    +3     
- Partials     2342     2343    +1     

☔ 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.

[claude]

❓ QUESTION: The members-grid "Send invite" action is a second invite entry point and keeps the old neutral wording.

Details

POST /organizations/{orgId}/users/send-invite (OrganizationUsersController.SendInviteToStagedUsers, no feature flag) goes through InviteStagedOrganizationUsersCommand.ReserveSeatsAsync, which calls organizationService.AutoAddSeatsAsync and returns new SeatExpansionFailed(ex.Message) — a BadRequestError whose message is surfaced per row to the caller. AutoAddSeatsAsync re-runs CanScaleAsync, so that message is SeatLimitHasBeenReachedMessage ("Seat limit has been reached.").

Result: an admin inviting staged members from the members grid at the autoscale cap sees the old wording, while the same admin inviting through Invite sees "Seat limit of 120 has been reached. Increase your seat limit to invite more members."

Since the substitution lives in InviteUsersAsync only, was the Design-approved wording scoped to the invite modal deliberately, or should ReserveSeatsAsync map the neutral message the same way? If it should, exposing ToInviteSeatLimitMessageAsync (or an equivalent mapper) rather than duplicating the comparison would keep the two paths in step.

[jrmccannon]

This looks good. Thanks for making those changes.