Upgrade Consent Portal to Support Consent Management API v0.3.0

[rashmithachamikara]

Purpose

Migrate the portal to Consent Management API v0.3.0. The previous portal contract depended on legacy client identifiers, fields, headers, update payloads, routes, and BFF-side metadata enrichment that are no longer required by the new API.

⚠️ EDIT 1: This PR merges the latest changes from the main branch (api v.0.3.0) into the feature/portal branch, then updates portal to support the new api changes. Nothing from the consent api or outside feature/portal is modified as part of this feature.

⚠️ EDIT 2: This PR now only includes commits related to new updates to portal, since the changes from main were introduced with #67 and #68

Goals

• Align the portal BFF and frontend with Consent API v0.3.0.
• Remove all legacy API compatibility behavior.
• Use the detailed consent response directly without recursive purpose and element enrichment calls.
• Improve consent registry pagination responsiveness.

Approach

Backend

• Replaced client-oriented configuration and headers with group-oriented equivalents:
  • PlaceholderClientID → PlaceholderGroupID
  • BFF_PROXY__PLACEHOLDER_CLIENT_ID → BFF_PROXY__PLACEHOLDER_GROUP_ID
  • TPP-client-id → group-id
• Updated the proxy allowlist for the v0.3 routes and HTTP methods.
• Migrated consent models to groupId, expirationTime, approved, mandatory, and versioned purpose/element identifiers.
• Updated approval requests to use stable purpose and element IDs and versions.
• Changed consent revocation from DELETE to POST.
• Made the BFF request detailed consent responses from the upstream API.
• Removed recursive purpose and element metadata enrichment. Consent details now come from a single detailed consent request.
• Updated the BFF OpenAPI contract, configuration examples, documentation, and integration tests.

Frontend

• Migrated consent types, fixtures, API requests, and components to the v0.3 contract.
• Displayed purpose and element display names where available.
• Replaced Client ID presentation with Group ID.
• Updated approval state and payloads to use purpose/element IDs and versions.
• Updated revocation requests to use POST.
• Prefetched the next consent registry page and removed the delayed loading-skeleton debounce to improve pagination responsiveness.
• Retained the existing consent registry, details, approval, and revocation user experience without adding administration or audit UI.

Screenshot/GIF:

User stories

• As a portal user, I can view consent details supplied by Consent API v0.3.0.
• As a portal user, I can see readable purpose and element display names.
• As a portal user, I can approve optional consent elements while mandatory and existing approvals are preserved.
• As a portal user, I can revoke a consent using the updated API operation.
• As a portal user, I can navigate between consent registry pages with reduced loading delay.

Release note

Updated the portal to support Consent Management API v0.3.0 and improved consent registry pagination performance.

Documentation

Updated:

• portal/backend/openapi/bff.yaml
• portal/backend/README.md
• portal/backend/.env.example
• portal/frontend/README.md

Automation tests

• Unit tests

  • Updated backend proxy and configuration tests for v0.3 routes, headers, and configuration.
  • Updated frontend component and API tests with v0.3 payloads.
  • Added coverage for next-page prefetching.
  • Coverage percentage was not measured.

• Integration tests

  • Updated BFF integration tests for detailed consent retrieval, version-aware approvals, and POST revocation.
  • Verified that consent details no longer trigger purpose or element metadata requests.
  • go test ./... passed.
  • pnpm lint, pnpm test, pnpm build, and pnpm format:check passed.

Security checks

• Followed secure coding standards: Yes
• Ran FindSecurityBugs plugin and verified report: N/A — the changed portal uses Go and TypeScript
• Confirmed that this PR does not commit keys, passwords, tokens, usernames, or other secrets: Yes

Migrations (if applicable)

This is a full migration with no backward-compatibility layer.

• Configure the BFF to use the Consent API v0.3.0 server.
• Replace BFF_PROXY__PLACEHOLDER_CLIENT_ID with BFF_PROXY__PLACEHOLDER_GROUP_ID.
• Remove any remaining deployment configuration that supplies the legacy key.
• Ensure upstream integrations use group-id instead of TPP-client-id.
• No portal database migration is required; the new database is configured separately.

The portal must not be deployed independently of the corresponding Consent API v0.3.0 deployment.

Test environment

• Operating system: Windows
• Backend: Go 1.26.3
• Frontend package manager: pnpm 10.6.5
• Frontend test environment: Vitest with jsdom
• Database: N/A for portal testing
• Browser: Not manually verified

Learning

The migration follows the v0.3 API contract as the authoritative source. With detailed consent responses now containing purpose and element metadata, the BFF can avoid sequential enrichment requests and return consent details with a single upstream call. TanStack Query prefetching is used to reduce perceived delay during registry pagination.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3749d5f2-a87b-4cad-bd75-64d524b0b660

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[hasithakn]

is the term phase 2 has set of features separately? else shall we have meaning full name?

[hasithakn]

@rashmithachamikara note this to fix on next PR you are sending refactoring the BFF code