BCH-1345: Leverage tab for browsing/subscribing to published export offerings

[saltpy-cs]

Summary

• New "Leverage" tab on the SSP editor: browse published export offerings from the cross-SSP catalog (GET /oscal/ssp-export-offerings) — title, description, version, and an item-count summary. Never surfaces anything upstream-scoped (no upstream SSP name/metadata is available in the catalog response by design, and this view never fetches one).
• Subscribe wizard: pick which offering items to inherit, mark which upstream responsibilities the downstream will satisfy per item, and supply Leveraged Authorization details (title, party UUID, optional date). Posts to POST /oscal/ssp-export-offerings/:id/subscribe (BCH-1338).
• Subscribe is gated behind both ssp-export-offering:subscribe and ssp:update (on the current/downstream SSP) via nested PermissionGates — mirroring the API's own dual server-side check, which also never evaluates ssp:read on the upstream SSP anywhere in the path.
• New SUBSCRIBE permission action constant, and CatalogOffering/CatalogOfferingItem/SSPLeverageLink/SubscribeRequest types matching the API's actual JSON shapes.

Test plan

• vue-tsc --build clean (project-wide, including test files)
• eslint clean
• New tests (SystemSecurityPlanLeverageView.spec.ts): offering list rendering, empty state, a dedicated trust-boundary test asserting the only URL ever fetched is the flat catalog endpoint, full subscribe round-trip (payload shape + success toast), blocked submit with zero items selected, and gating on either/both permissions
• Full npm run test:unit suite green aside from one pre-existing, unrelated LoginView.spec.ts failure (localStorage env issue predating this change)
• Manually verified in a local demo environment: published a real offering on one SSP, subscribed from another, and confirmed via the (BCH-1338/1341) projection endpoint that the inherited claim, satisfied responsibility, and leveraged authorization were all created correctly with satisfaction computed as full

Summary by CodeRabbit

• New Features

  • Added a Leverage tab for browsing available security plan offerings.
  • Added offering details, item selection, responsibility tracking, and authorization fields.
  • Added subscription workflow with validation, progress feedback, success and error notifications.
  • Added permission controls for viewing and subscribing to offerings.
  • Added support for catalog offering and leverage subscription data.

• Tests

  • Added coverage for offering display, subscription submission, validation, permissions, and empty states.

[coderabbitai]

Warning

Review limit reached

@saltpy-cs, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 42 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 912ea414-8f37-421d-8a0d-86416daf2ca2

📥 Commits

Reviewing files that changed from the base of the PR and between 93d6a79 and e4bc535.

📒 Files selected for processing (2)

• src/components/system-security-plans/SubscribeOfferingWizard.vue
• src/views/system-security-plans/__tests__/SystemSecurityPlanLeverageView.spec.ts

📝 Walkthrough

Walkthrough

Adds an SSP Leverage page that retrieves catalog offerings, displays subscription actions under permission gates, and opens a wizard to submit selected items, responsibilities, and leveraged authorization details.

Changes

SSP leverage subscription

Layer / File(s)	Summary
Subscription contracts and permissions src/types/ssp-export-offerings.ts, src/types/ssp-leverage.ts, src/constants/permissions.ts	Adds catalog offering types, subscription request/response contracts, and the subscribe permission action with tooltip wording.
Leverage navigation and offering page src/router/index.ts, src/views/system-security-plans/SystemSecurityPlanEditorView.vue, src/views/system-security-plans/SystemSecurityPlanLeverageView.vue	Adds the Leverage route and tab, retrieves catalog offerings, summarizes items, and manages permission-gated subscription dialogs.
Offering subscription wizard src/components/system-security-plans/SubscribeOfferingWizard.vue	Adds item and responsibility selection, leveraged authorization fields, validation, authenticated submission, toast feedback, and subscription events.
Leverage flow validation src/views/system-security-plans/__tests__/SystemSecurityPlanLeverageView.spec.ts	Tests rendering, catalog retrieval, subscription payloads, validation errors, success feedback, and permission visibility.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant LeverageView
  participant CatalogAPI
  participant SubscribeOfferingWizard
  participant AuthenticatedAxios

  User->>LeverageView: Open Leverage tab
  LeverageView->>CatalogAPI: Fetch catalog offerings
  CatalogAPI-->>LeverageView: Return offerings
  User->>LeverageView: Select Subscribe
  LeverageView->>SubscribeOfferingWizard: Open selected offering
  User->>SubscribeOfferingWizard: Select items and enter authorization
  SubscribeOfferingWizard->>AuthenticatedAxios: POST subscription request
  AuthenticatedAxios-->>SubscribeOfferingWizard: Return leverage links
  SubscribeOfferingWizard-->>LeverageView: Emit subscribed event

Loading

Suggested reviewers: gusfcarvalho

Poem

A rabbit hops through offerings bright,
Checks each control with care and light.
Authorization fields align,
A subscribe request makes links shine.
“Leverage!” cheers the bunny crew.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly matches the main change: adding a Leverage tab for browsing and subscribing to published export offerings.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/system-security-plans/SubscribeOfferingWizard.vue`:
- Around line 175-205: Prevent re-entry in submit() by returning immediately
when submitting.value is already true, before performing validation or
constructing the request. Preserve the existing submitting state lifecycle for
the initial submission.

In
`@src/views/system-security-plans/__tests__/SystemSecurityPlanLeverageView.spec.ts`:
- Line 147: Move the regular expression used by the expectation in
SystemSecurityPlanLeverageView.spec.ts to module scope, then reuse that
module-level constant in the not.toMatch assertion to satisfy
e18e/prefer-static-regex.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: c064f8d4-fb45-4af2-925d-e66e236e8caf

📥 Commits

Reviewing files that changed from the base of the PR and between 40e1dc2 and 93d6a79.

📒 Files selected for processing (8)

• src/components/system-security-plans/SubscribeOfferingWizard.vue
• src/constants/permissions.ts
• src/router/index.ts
• src/types/ssp-export-offerings.ts
• src/types/ssp-leverage.ts
• src/views/system-security-plans/SystemSecurityPlanEditorView.vue
• src/views/system-security-plans/SystemSecurityPlanLeverageView.vue
• src/views/system-security-plans/__tests__/SystemSecurityPlanLeverageView.spec.ts