[PM-38481] Add Staged Filter for Organization Members

[sven-bitwarden]

🎟️ Tracking

PM-38481

📔 Objective

We are introducing Staged as a new OrganizationUserStatusType to support automatically-provisioned users. Following our current UI practice, we're adding a new filter to the organization users members page to represent this new status.

Note

Bitwarden SDK does not yet support this status. This PR introduces a temporary map between the SDKs OrganizationUserStatusType, and the frontend's. The area affected does not apply to Staged users, so it is a safe bet, but we could alternatively wait until the SDK's updated before merging this PR.

📸 Screenshots

Staged tooltip (hover works I swear)

Staged disappears when I remove 'em all

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the addition of the Staged organization-user status filter on the web members page: the new stagedUserCount tally and peopleFilter behavior in people-table-data-source.ts, the Staged toggle/badges in members.component.html, the UserStatusPipe Staged case, the SDK-backed enum re-export, and the new i18n keys. Test coverage was added for the filter, status counts, and pipe, and all of it traces correctly. Prior review feedback (pipe case, status badges, @deprecated JSDoc, tooltip wording, and the SDK version-bump chain) has been resolved in the threads and the current diff.

Code Review Details

No new findings.

Notes considered and intentionally not flagged:

• stagedUserCount references OrganizationUserStatusType.Staged directly instead of this.statusType.Staged. This is correct: ProviderUserStatusType has no Staged member, and providers never carry that status, so the provider tally stays 0 as intended.
• The Staged badge in the avatar table view omits [addTooltipToDescribedby], but this matches the existing per-block convention (the adjacent Revoked badge in the same block omits it too), so it is consistent rather than a regression.
• The staged / stagedMemberTooltip i18n keys are used only within apps/web, so web-only placement is correct.

Dependency Changes

Package	Change	Ecosystem
@bitwarden/sdk-internal	0.2.0-main.859 → 0.2.0-main.860	npm
@bitwarden/commercial-sdk-internal	0.2.0-main.859 → 0.2.0-main.860	npm

These are internal, already-approved Bitwarden SDK packages bumped to land the Staged status, consistent with the discussion in the PR threads. No new external dependencies.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 49.32%. Comparing base (84dd901) to head (9d24cad).
⚠️ Report is 9 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...p/admin-console/common/people-table-data-source.ts	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #21394      +/-   ##
==========================================
- Coverage   49.32%   49.32%   -0.01%     
==========================================
  Files        4092     4096       +4     
  Lines      128649   128834     +185     
  Branches    19753    19759       +6     
==========================================
+ Hits        63461    63543      +82     
- Misses      60489    60581      +92     
- Partials     4699     4710      +11     

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[eliykat]

Changes LGTM, just waiting on SDK changes as discussed. You should be able to:

• update the enum definition in the SDK
• after your SDK changes have merged, bump the SDK version used by your PR here to bring in the latest changes (see SDK README for how SDK changes are published)
• bonus points! delete the TS definition of this enum and re-export the SDK definition from the same location, so that we only rely on the SDK definition instead of redefining it. I did this for the PolicyType enum.

[sven-bitwarden]

@eliykat Since your review I've added the labels that are missing along with the hover-tooltip, and from our x-team discussion I've hidden the filter when there are no staged users.

[sven-bitwarden]

@claude have another review you beautiful little menace.

[claude]

Claude finished @sven-bitwarden's task in 4m 1s —— View job

---

Code Review — Staged filter

Re-reviewed against origin/main. The earlier feedback is addressed: the UserStatusPipe now has a Staged case, both row layouts render a Staged badge + tooltip, the toggle is hidden when stagedUserCount === 0, and the client-owned enum is gone in favour of re-exporting the SDK definition (nice — exactly what @eliykat asked for). One finding I'd want resolved before merge, plus a couple of minor notes.

---

⚠️ IMPORTANT — default-new-policy.service.spec.ts test is stale and should now fail

The test "maps a Staged organization status to the SDK Invited status" (default-new-policy.service.spec.ts:128-143) still asserts the old mapping behaviour, but the mapping it describes was deleted in commit 64320a4.

The test comment says "the boundary mapper's default branch should map it to the nearest pre-membership status, Invited" — but toSdkOrganizationUserPolicyContext now passes the status straight through:

// default-new-policy.service.ts:88
status: organization.status,   // the toSdkOrganizationUserStatus() mapper was removed

Because the client enum is now a pure re-export of the SDK enum, an org constructed with OrganizationUserStatusType.Staged carries the SDK Staged value, so sdkOrgs[0].status will be Staged, not Invited — the assertion on line 142 can't hold. This test should be failing.

Note the visible PR checks (Build/Scan/Code Quality/Chromatic) don't include the Jest unit suite, so a red unit test wouldn't surface here. Please run it locally:

npm test -- default-new-policy

Then either delete this test (the mapping it covered no longer exists) or rewrite it to assert that Staged now passes through unchanged. Fix this →

❓ Confirm the SDK actually exports Staged at 0.2.0-main.860

Since OrganizationUserStatusType is now just a re-export of the SDK enum, the entire feature depends on the SDK build genuinely containing Staged. If Staged isn't in the published 0.2.0-main.860, then OrganizationUserStatusType.Staged resolves to undefined and everything silently no-ops — stagedUserCount is always 0 (toggle never appears), the pipe/badges never match, and user-status.pipe.spec.ts / people-table-data-source.spec.ts would still pass coincidentally (matching undefined === undefined). Worth a quick sanity check that the bumped SDK really resolves Staged to a defined value before merge.

🟢 Minor — stagedUserCount hardcodes the enum instead of this.statusType

people-table-data-source.ts:104-105 uses OrganizationUserStatusType.Staged directly while every sibling count uses this.statusType.*. This is understandable — this.statusType may be ProviderUserStatusType, which has no Staged — and it's harmless (no provider status collides with the Staged value, and stagedUserCount isn't shown in the provider UI). Optional: a one-line comment noting why it deviates would save the next reader a double-take.

🟢 Minor — tooltip a11y attribute differs between the two badge layouts

The first badge (members.component.html:234) omits [addTooltipToDescribedby]="true", while the second (line 293) sets it. If both Staged badges should be equivalent for screen-reader users, consider matching them.

---

Nothing else stands out — the i18n keys are web-scoped correctly, the filter logic and counts are well tested, and the default-branch fallthrough in the pipe is fine. The single blocker is the stale unit test; the rest are optional polish.
· branch ac/pm-38481/add-staged-filter-to-members-page

[eliykat]

Thanks for doing the SDK dance. 🦀

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[eliykat]

LGTM once CI issues are resolved.