Agreements - Status and mandatory/optional state management

[jjeroch]

Note this ticket is a reference ticket of the in consortia development ++ additionally one sub-ticket of the in gitHub managed scope. The internal consortia tickets wont get published as sub-tasks; the content is directly displayed inside the feature

TASK1

Scope

• Rework agreement table content
• Update seeding data
• enable agreement status to flag inactive/not anymore supported agreements
• implement a new db view for agreements

 

Details

---

 

1. Agreement table update

In the current portal.agreements table; 1 unnecessary attributes is stored

• agreement_type

Please remove this value from the table as well as from the seeding data.

If this has impact on any code; please update the code as well and check if we need a kind of deletion script for the application release package.

 

 

Additionally we need new attributes/flags

• flag: mandatory
• status (values: ACTIVE; INACTIVE)

 

2. Update seeding data // 3. enable agreement status to flag inactive/not anymore supported agreements

• Agreement status
  • set agreement id "aa0a0000-7fbc-1f2f-817f-bce0502c1090" to "INACTIVE"
  • all other agreements to be set to "ACTIVE"
• Agreement flag
  • set all agreement ids to "mandatory"

 

 

 

With the latest updates of the standardization and conformity process; some minor changes are getting active which result into a needed change of the portal seeding data file.

Additionally update of dev/int/stable needed.

 

API Endpoint To Dos!

---

 

• GET /api/registration/companyRoleAgreementData
  • update business logic to only respond with those agreements which are "ACTIVE"
• GET /api/registration/application/{applicationId}/companyRoleAgreementConsents
  • update business logic to only respond with those agreements which are "ACTIVE"
• POST /api/registration/application/{applicationId}/companyRoleAgreementConsents
  • if inside the request body any agreement consent is stated; where the actual agreement status is "INACTIVE" , do not set any consent; ignore the record
• GET /api/administration/companydata/companyRolesAndConsents
  • update business logic to only respond with those agreements which are "ACTIVE"
• POSt /api/administration/companydata/companyRolesAndConsents
  • if inside the request body any agreement consent is stated; where the actual agreement status is "INACTIVE" , do not set any consent; ignore the record

 

 

VIEW Implementation

---

 

Enable a db view where agreements; agreements assignment (portal.agreement_assigned_company_roles) and their status and mandatory flag can get viewed

 

Example Table:

Agreement ID | Agreement Name | Agreement Company Role | Agreement Status | Mandatory -- | -- | -- | -- | -- uuid | Security Regulations - Active Participant | ACTIVE_PARTICIPANT | ACTIVE | true uuid | Terms & Conditions - Service Marketplace | SERVICE_PROVIDER | INACTIVE | true uuid | Data Sovereignty Guidelines | APP_PROVIDER | ACTIVE | false

 

---

TASK2

Scope

Update GET /agreementData endpoints by adding per agreement the mandatory state

API Endpoint To Dos!

• GET /api/registration/companyRoleAgreementData add inside the endpoint response the attribute "mandatory" to display the agreements.mandatory flag per agreement. The value should be ideally "true"/"false"
• GET /api/administration/companydata/companyRolesAndConsents add inside the endpoint response the attribute "mandatory" to display the agreements.mandatory flag per agreement. The value should be ideally "true"/"false"

---

TASK3

Scope

In the implementation of the TASK#1 we did miss a couple of endpoints - those are managed in this ticket.

Details API Endpoint To Dos!

• GET /api/apps/AppReleaseProcess/agreementData update business logic to only respond with those agreements which are "ACTIVE" add inside the endpoint response the attribute "mandatory" to display the agreements.mandatory flag per agreement. The value should be ideally "true"/"false"

• GET /api/apps/AppReleaseProcess/consent/{appId} update business logic to only respond with those agreements which are "ACTIVE"

• POST /api/apps/AppReleaseProcess/consent/{appId}/agreementConsents if inside the request body any agreement consent is stated; where the actual agreement status is "INACTIVE" , do not set any consent; ignore the record

• GET /api/Apps/appAgreementData/{appId} update business logic to only respond with those agreements which are "ACTIVE" add inside the endpoint response the attribute "mandatory" to display the agreements.mandatory flag per agreement. The value should be ideally "true"/"false"

• POST /api/Apps/{appId}/subscribe if inside the request body any agreement consent is stated; where the actual agreement status is "INACTIVE" , do not set any consent; ignore the record

• GET /api/services/ServiceReleaseProcess/agreementData update business logic to only respond with those agreements which are "ACTIVE" add inside the endpoint response the attribute "mandatory" to display the agreements.mandatory flag per agreement. The value should be ideally "true"/"false"

• GET /api/services/ServiceReleaseProcess/consent/{appId} update business logic to only respond with those agreements which are "ACTIVE"

• POST /api/service/ServiceReleaseProcess/consent/{appId}/agreementConsents if inside the request body any agreement consent is stated; where the actual agreement status is "INACTIVE" , do not set any consent; ignore the record

• GET /api/service/serviceAgreementData/{appId} update business logic to only respond with those agreements which are "ACTIVE" add inside the endpoint response the attribute "mandatory" to display the agreements.mandatory flag per agreement. The value should be ideally "true"/"false"

• POST /api/services/{serviceId}/subscribe if inside the request body any agreement consent is stated; where the actual agreement status is "INACTIVE" , do not set any consent; ignore the record

---

FE Tickets

• [ ] https://github.com/eclipse-tractusx/portal-frontend-registration/issues/130
• [ ] https://github.com/eclipse-tractusx/portal-frontend/issues/584
• [ ] https://github.com/eclipse-tractusx/portal-frontend/issues/608
• [ ] https://github.com/eclipse-tractusx/portal-frontend/issues/609
• [ ] https://github.com/eclipse-tractusx/portal-frontend/issues/610

[jjeroch]

Linked:

• [ ] https://github.com/eclipse-tractusx/portal-frontend-registration/issues/130

[stephanbcbauer]

Hello @jjeroch , @evegufy

Since the feature is a 24.05 feature and the development phase for 24.08 is coming to an end, we need a status on the feature. Can you please update the status?

• [ ] Currently you are assigned (Responsible) → Is this correct? If not, please assign the correct contact person
• [ ] Please check whether the status (backlog, work in progress ...) is set correctly
• [ ] Please comment on the current status of the feature
• [ ] Are all SubTasks (issues from other repositories that deal with the feature) linked? → The easiest way is to mention the feature here in the issue (via the ID) so we can see which teams/repositories are involved.
• [ ] Is there a spillover planned?

If you need any clarification, please get in touch, thank you very much.

Stephan