Compliance overlays: show Fix task links

Task 5411 · Done · Coder · created · updated

Defect (found by the epic 5303 finish check; 5325 deferred it as "tasks:view filter on overlays"). Observed (code read): `GET /api/compliance/matrix` and `GET /api/compliance/repos/{id}` require only `compliance:view` (apps/api/app/routes/compliance.py:369-370, 496-497). They embed each remediation overlay from `Overlay.out()` (apps/api/app/governance/remediation.py:196-198): task_id, status, kind, an open PR's `pr_url` and campaign_id. `_task_overlays` (:208-212) loads Task rows by id with no permission check. So a compliance viewer who may not view tasks on that project still sees the Fix task id, its state and its PR link. The data is same-org, so this is low severity, but it bypasses the tasks permission. Fix: in the two read routes, pass overlays through a filter. For a project where the principal lacks tasks:view, return the overlay's `status` only (so the badge still reads "fix in progress") and null out `task_id`, `pr_url` and `campaign_id`. Apply the same rule to campaign_summary's task-identifying fields. Use the existing authz helper the tasks routes use for tasks:view; register the check site in test_authz_policy if that test requires it. Done means: - An API test: a user with compliance:view and no tasks:view gets overlays with status set and task_id/pr_url/campaign_id null. A user with both gets them populated. - The web badge renders without a link when task_id is null (existing OverlayBadge test extended). - `./dc check full` is green. Out of scope: Fix filing, locking, campaign creation, any other compliance route.

Outcome

Compliance overlays now honour tasks:view: without it, a viewer sees the status only, with null task_id/pr_url/campaign_id and an unlinked badge. Full gate green, PR #4705 merged, Jaah Deploy succeeded. Deferred: target_task_id is still unfiltered.

Pull request

Artifacts

Activity

  • Ready
  • Runner started
  • Runner ended (done)