[PM-32066] - Add Org Ability View

[jrmccannon]

🎟️ Tracking

PM-32066

📔 Objective

This adds a dedicated SQL View for the Organization Ability. This includes a new repository method and integration tests validating it correctly maps those fields. It will be used in future stories.

[claude]

Claude finished @jrmccannon's task in 5m 16s —— View job

---

I'll analyze this and get back to you.

[github-actions]

Checkmarx One – Scan Summary & Details – 186d388d-832f-4a17-a2c5-d2b52710d1c5

---

Fixed Issues (1)

Great job! The following issues were fixed in this Pull Request

Severity	Issue	Source File / Package
	CSRF	/src/Api/KeyManagement/Controllers/AccountsKeyManagementController.cs: 202

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.50%. Comparing base (c7c17e8) to head (527e9f1).
⚠️ Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7194      +/-   ##
==========================================
+ Coverage   57.39%   61.50%   +4.10%     
==========================================
  Files        2031     2032       +1     
  Lines       89273    89394     +121     
  Branches     7935     7944       +9     
==========================================
+ Hits        51235    54978    +3743     
+ Misses      36195    32491    -3704     
- Partials     1843     1925      +82     

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

[JimmyVo16]

Some small questions, but overall it looks good.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
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

[rkac-bw]

Nice work on the view and per-ID sproc. This is a solid foundation.

One question though: is FusionCache part of this change, like the org abilities example in CACHING.md, or is that happening in a follow-up?

The reason I ask is the current bulk Organization_ReadAbilities only runs around ~1K times per hour. If callers move to per-ID lookups without a cache layer in front of it, that likely turns into something closer to 500–700K DB round trips per hour based on current sync and cipher volume. With FusionCache and stampede protection, that should stay much closer to ~10–15K per hour since you only pay once per unique org per TTL window.

[jrmccannon]

Nice work on the view and per-ID sproc. This is a solid foundation.

One question though: is FusionCache part of this change, like the org abilities example in CACHING.md, or is that happening in a follow-up?

The reason I ask is the current bulk Organization_ReadAbilities only runs around ~1K times per hour. If callers move to per-ID lookups without a cache layer in front of it, that likely turns into something closer to 500–700K DB round trips per hour based on current sync and cipher volume. With FusionCache and stampede protection, that should stay much closer to ~10–15K per hour since you only pay once per unique org per TTL window.

FusionCache is a later update we will be making.

[rkac-bw]

Nice work on the view and per-ID sproc. This is a solid foundation.
One question though: is FusionCache part of this change, like the org abilities example in CACHING.md, or is that happening in a follow-up?
The reason I ask is the current bulk Organization_ReadAbilities only runs around ~1K times per hour. If callers move to per-ID lookups without a cache layer in front of it, that likely turns into something closer to 500–700K DB round trips per hour based on current sync and cipher volume. With FusionCache and stampede protection, that should stay much closer to ~10–15K per hour since you only pay once per unique org per TTL window.

FusionCache is a later update we will be making.

Thanks! Makes sense. Is the plan to have FusionCache wired up before the caller migration PRs (#7202,
#7214, #7240) start landing? Just want to make sure we want to be aware if there will be a window where per-ID calls are hitting the DB uncached.

[JimmyVo16]

Thanks! Makes sense. Is the plan to have FusionCache wired up before the caller migration PRs (#7202,
#7214, #7240) start landing? Just want to make sure we want to be aware if there will be a window where per-ID calls are hitting the DB uncached.

Yes, we’re going to migrate to FusionCache and eventually move away from Organization_ReadAbilities completely.

The PRs that you posted will call the new interfaces, but the underlying implementations will still use the existing cache. It will not trigger a database call if they’re not in the cache, since Organization_ReadAbilities is called by a scheduler at 10-minute intervals rather than by cache requests, so I don’t think this change will increase the rate of requests.

We have future tickets that will change the implementation to call per request ID and cache it appropriately with FusionCache.