[PM-37470] Add UseRiskInsights data migration for existing Enterprise organizations

[AlexRubik]

🎟️ Tracking

PM-37470
Parent epic: PM-37469

📔 Objective

Add the data migration step from the Organization Ability README for UseRiskInsights. Sets UseRiskInsights = 1 on every existing Organization row with an Enterprise plan type (4, 5, 10, 11, 14, 15, 19, 20). Covers MSSQL (cloud) and the three EF providers (MySQL, Postgres, SQLite) used by self-host.

The column has existed since 2024-11-25_00_AddUseRiskInsightsToOrganization.sql but the README's step 4 (data migration for existing orgs) was never performed. A stopgap one-off datafix (DBOPS-59) handled cloud in Dec 2025, but orgs created since are missing the flag and self-host instances never received it. This PR delivers the proper repeatable migration.

Re-runs are no-ops: MSSQL uses a WHERE UseRiskInsights = 0 guard so the batched loop exits immediately when there is nothing to update; EF variants set 1 over 1 which is idempotent by construction.

Other subtasks under the parent epic handle plan-definition mapping (PM-37471), admin portal toggle (PM-37473), self-host license claims (PM-37474), re-enabling the endpoint guard (PM-37475), and client-side divergence (PM-37476).

Mirrors the pattern from PM-35253 (#7489) UseInviteLinksDataMigration. SQL formatted per the Bitwarden SQL style guide (each top-level keyword on its own line).

🤖 Testing

The IMigrationTesterService infrastructure was disabled in PM-37482 (#7633, May 14 2026) due to flakiness, so no automated migration integration test ships with this PR. Verification is manual:

• Seed local MSSQL with one org per Enterprise plan type (4, 5, 10, 11, 14, 15, 19, 20) and a non-Enterprise control, all with UseRiskInsights = 0.
• Apply migration. Confirm all Enterprise rows flip to 1 and the non-Enterprise row stays at 0.
• Re-run the script. Confirm the batched loop exits on first iteration with @@ROWCOUNT = 0.
• On at least one EF provider (MySQL, Postgres, or SQLite), seed equivalent rows and apply the migration via dotnet ef database update. Confirm same outcome.

If this PR sits in review across a calendar shift, rename the MSSQL script's date prefix to the actual merge date.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.05%. Comparing base (c27eebb) to head (d4cc007).
⚠️ Report is 36 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7691      +/-   ##
==========================================
+ Coverage   64.85%   65.05%   +0.20%     
==========================================
  Files        2140     2147       +7     
  Lines       94622    95184     +562     
  Branches     8443     8526      +83     
==========================================
+ Hits        61370    61926     +556     
+ Misses      31156    31137      -19     
- Partials     2096     2121      +25     

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

[github-actions]

Bitwarden Claude Code Review

Overall Assessment: APPROVE

This PR delivers the step 4 data migration from the Organization Ability README for UseRiskInsights, setting the flag to 1 on existing Enterprise organizations across MSSQL and the three EF providers (MySQL, Postgres, SQLite). The implementation cleanly mirrors the recently-merged UseInviteLinksDataMigration pattern (#7489), and the plan-type IDs (4, 5, 10, 11, 14, 15, 19, 20) match every Enterprise variant in src/Core/Billing/Enums/PlanType.cs. The underlying column [UseRiskInsights] BIT NOT NULL DEFAULT (0) (added 2024-11-25) makes the unguarded EF UPDATEs safe, and the MSSQL WHILE/@@ROWCOUNT batched loop terminates correctly thanks to the WHERE [UseRiskInsights] = 0 guard. The latest commit tightening the EF Up() statements with the same = 0 guard is a nice improvement over the prior UseInviteLinks migration.

Code Review Details

No findings.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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

[AlexRubik]

@claude review this again pleaseee

[claude]

Claude finished @AlexRubik's task in 1m 43s —— View job

---

Claude Code Review (re-review)

• Read MSSQL data migration script
• Read EF Up()/Down() migration files (MySQL, Postgres, SQLite)
• Verify Enterprise plan-type IDs against PlanType.cs
• Verify column type and prior schema migration
• Compare against UseInviteLinksDataMigration reference pattern
• Post review findings

Overall Assessment: APPROVE — no new findings since the prior review.

Verification notes

• Plan-type IDs are complete and correct. (4, 5, 10, 11, 14, 15, 19, 20) cover every Enterprise variant in src/Core/Billing/Enums/PlanType.cs:16-48 (2019, 2020, 2023, current). No Enterprise plan is missed; no non-Enterprise plan is included.
• Underlying column is safe to update unconditionally. 2024-11-25_00_AddUseRiskInsightsToOrganization.sql:2 defines [UseRiskInsights] BIT NOT NULL DEFAULT (0), so the EF UPDATE ... SET UseRiskInsights = 1 cannot violate NOT NULL or read NULL.
• MSSQL batched loop terminates correctly. WHILE @RowsAffected > 0 + the AND [UseRiskInsights] = 0 guard at util/Migrator/DbScripts/2026-05-21_00_UseRiskInsightsDataMigration.sql:17 guarantees the loop exits on first pass when there's nothing to do. Idempotent re-runs are no-ops.
• EF Up() guard is an improvement over the reference. The AND UseRiskInsights = 0/false clause in all three EF Up() blocks (vs. unconditional UPDATE in 20260416151346_UseInviteLinksDataMigration.cs:16) avoids touching already-set rows. Nice tightening per the commit d4cc007.
• SQL formatting matches the Bitwarden SQL style guide. Top-level keywords (UPDATE, SET, WHERE, AND) each on their own line. Consistent with the fc1342b formatting fix.
• EF migration timestamp ordering is clean. 20260521164709 (Postgres) / 20260521164730 (MySQL) / 20260521164638 (SQLite) all sort after 20260518143024_AddOrganizationPlanMigrationCohort — no apply-order surprises.
• Provider boolean encoding is correct per dialect. MySQL/SQLite use 1/0; Postgres uses true/false. Matches the column types defined in each provider's snapshot.
• Down() behavior matches established precedent. The EF Down() resets every Enterprise org's UseRiskInsights to 0, which would clobber any value manually toggled in the Bitwarden Portal. This mirrors UseInviteLinksDataMigration's Down() exactly, and rolling back a data migration is inherently best-effort — flagging it for awareness, not as a blocker.

Observation (not a blocker)

The PR description already calls this out: if the PR sits in review past calendar shifts, the MSSQL filename 2026-05-21_00_UseRiskInsightsDataMigration.sql should be renamed to the actual merge date prefix so it slots into the correct chronological position in util/Migrator/DbScripts/. Today is 2026-05-28, so still fine.
| Branch: dirt/pm-37470/use-risk-insights-data-migration

[rkac-bw]

Add trailing:
GO