Upgrade Consent Portal to Support Consent Management API v0.3.0 - #65
Upgrade Consent Portal to Support Consent Management API v0.3.0#65rashmithachamikara wants to merge 112 commits into
Conversation
…running pattern of expiration job
- Fix response examples to match the documented schema fields and time units.
- Created a new test file for consent history tests, covering scenarios such as: - New consent having empty history. - Updating consent creating history with pre-update snapshot. - Revoking consent creating history. - Expiry of consent creating history. - Adding and updating authorizations creating history. - Testing inclusion of status history in consent retrieval. - Enabled history tracking in integration test deployment configurations.
- Update readme - Update test suite
…story Consent History
- Update /consents/
- Update /consents/{consentId}
- Update tests
- Update docs
…mes-in-consent-get Add element and purpose display names to consent get response
Add v0.3.0 changes
- Introduce details flag to consent endpoints - Update documentation
- Update stores and queries - Update tests - Update docs
…mes-in-consent-get Display names in consent get and purpose get
- Merge after adding display name and description to consent get
…ortal backend Instead, now it rely on details=true flag of consent endpoints
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
| sleep 2 | ||
| done | ||
| - name: 🔨 Build Server Binary for Integration Tests |
There was a problem hiding this comment.
Need this for the main branch only?
There was a problem hiding this comment.
These are not introduced as part of this PR.
This PR merges the latest changes from the main branch (api v.0.3.0) into the feature/portal branch, then makes changes to portal to support new api changes. Nothing from the consent api or outside feature/portal is modified.
Only the changes starting from 7c0d5bd are explicitly introduced here.
Commits before these were already reviewed when those were merged to the main branch
There was a problem hiding this comment.
The reason this was originally removed is that it is now built automatically by build.sh test_integration. There is no need to build it separately beforehand.
There was a problem hiding this comment.
Shall we send a separate PR to sync the main branch into the feature/portal branch? And then update this PR?
Otherwise it's hard to review just the features this PR is intended for.
| @@ -18,7 +18,7 @@ info: | |||
| name: Apache 2.0 | |||
| url: http://www.apache.org/licenses/LICENSE-2.0.html | |||
| servers: | |||
| - url: http://localhost:8080/api/v1 | |||
| - url: http://localhost:8060/api/v1 | |||
There was a problem hiding this comment.
Why does a port change is required?
There was a problem hiding this comment.
This is also not part of this feature.
8080 is commonly used for many applications. Conventionally, it is widely used as an alternative web server port. The port change is to avoid potential port clashes with other applications running on a system. Additionally, openfgc does not function as a publicly exposed web server (which commonly uses 8080)
|
|
||
| servers: | ||
| - url: https://localhost:3000/api/v1 | ||
| - url: https://localhost:8060/api/v1 |
There was a problem hiding this comment.
Port change required?
There was a problem hiding this comment.
Same as above
6 participants
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.
feature/portalis modified as part of this feature.Only the changes starting from 7c0d5bd (~ last 10 commits) are explicitly introduced here.
Commits before these were already reviewed when those were merged to the main branch
Goals
Approach
Backend
PlaceholderClientID→PlaceholderGroupIDBFF_PROXY__PLACEHOLDER_CLIENT_ID→BFF_PROXY__PLACEHOLDER_GROUP_IDTPP-client-id→group-idgroupId,expirationTime,approved,mandatory, and versioned purpose/element identifiers.DELETEtoPOST.Frontend
POST.Screenshot/GIF:
User stories
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.yamlportal/backend/README.mdportal/backend/.env.exampleportal/frontend/README.mdAutomation tests
Unit tests
Integration tests
POSTrevocation.go test ./...passed.pnpm lint,pnpm test,pnpm build, andpnpm format:checkpassed.Security checks
Migrations (if applicable)
This is a full migration with no backward-compatibility layer.
BFF_PROXY__PLACEHOLDER_CLIENT_IDwithBFF_PROXY__PLACEHOLDER_GROUP_ID.group-idinstead ofTPP-client-id.The portal must not be deployed independently of the corresponding Consent API v0.3.0 deployment.
Test environment
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.