Email collection approvers when an access request needs a decision

[maxkpower]

🎟️ Tracking

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

📔 Objective

Emails a collection's approvers when an access request is waiting on their decision. Until now the only signal was the RefreshApproverInbox push, which reaches a client only if one is already open, so an approver could be the sole reason a requester was blocked and never learn they were asked.

• One email per request, naming the requester, the requested window, and linking to that request. There is no throttling or summarising.
• Fires only on the human approval path. An automatically approved request has no approver waiting, and sends nothing.
• Recipients are the collection's managers minus the requester, who may manage it but may not decide their own request.
• The mail names no collection, cipher, or reason. Collection and cipher names are ciphertext the server cannot read; the reason is plaintext but deliberately withheld from an HTML body. The link is the only route to that detail.

Second of four in a stack on pam/uat. Sits on the mailer plumbing PR.

📸 Screenshots

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the new ApproverMailNotifier and its interface, the wiring into the human-approval branch of SubmitAccessRequestCommand, the AccessRequestPendingView mail model with its MJML/Handlebars templates, and the accompanying unit tests. Recipients come from ICollectionRepository.GetManagingUserIdsAsync — the same set already receiving the RefreshApproverInbox push, and one the repository integration tests confirm excludes unconfirmed members — minus the requester, whose exclusion matches the self-decision refusal in DecideAccessRequestCommand, so no new authorization surface is opened. The body carries only the organization name, requester address, window and a request link; no collection or cipher names and no Reason, and the window is safe to label UTC because AccessRequestCreateRequestModel.ToSubmission normalizes Start/End through PamRequestDateTimeExtensions on the only path into the command. Failure handling matches the documented IAccessMailNotifier contract — reads and sends are wrapped so a mail outage cannot fail the submit, only ids are logged — and the escaping test plus the rendering test cover the {{OrganizationName}} interpolation and the template resource names.

Code Review Details

No findings.

[codecov]

Codecov Report

❌ Patch coverage is 98.57143% with 1 line in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (pam/PM-42817/mail-plumbing@cc12bac). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
.../src/Services/Pam/Services/ApproverMailNotifier.cs	98.18%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                      Coverage Diff                      @@
##             pam/PM-42817/mail-plumbing    #8290   +/-   ##
=============================================================
  Coverage                              ?   64.36%           
=============================================================
  Files                                 ?     2585           
  Lines                                 ?   111240           
  Branches                              ?     9934           
=============================================================
  Hits                                  ?    71595           
  Misses                                ?    37273           
  Partials                              ?     2372           

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