diff --git a/CHANGELOG.md b/CHANGELOG.md index 60ad71fc9..0ac753ce8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,19 @@ New features, fixed bugs, known defects and other noteworthy changes to each release of the Catena-X Portal Assets. +## 1.7.0-RC3 + +### Change +* useCase content file updated +* images linked for traceability useCase exchanged +* portal database upgrade documentation updated + +### Feature +n/a + +### Bugfix +n/a + ## 1.7.0-RC2 ### Change diff --git a/developer/Technical Documentation/Version Upgrade/portal-upgrade-details.md b/developer/Technical Documentation/Version Upgrade/portal-upgrade-details.md index c9c07ce0a..388c8fdaa 100644 --- a/developer/Technical Documentation/Version Upgrade/portal-upgrade-details.md +++ b/developer/Technical Documentation/Version Upgrade/portal-upgrade-details.md @@ -7,6 +7,75 @@ Each section includes the respective change details, impact on existing data and > **_INFO:_** inside the detailed descriptions below, the definition 'migration script' refers to the term 'migrations' as it is defined by the ef-core framework: https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations +
+ +#### Enable OSP Provider IdPs - Update - 1.7.0 + +The `identity_providers` table has been adjusted to provide the possibility to safe the owner of the idp. + +image + +- added "Identity_Provider_Types" table which is connected to portal.identity_providers table +- added inside the new table "Identity_Provider_Types" an id as well as a label. Labels are defined below: + - own + - managed + - shared +- additionally a new attribute identity_providers.owner_id is added + - in case the type is "own" - the owner is always the same company as the IdP connected company + - in case the type is "managed" - the owner is the company which created the IdP (OSP or Operator) + - in case the type is "shared" - the owner is the same company as the IdP connected company + +the identity_providers.owner is important to define which companies are able to create users linked to this idp + +- added new process_type PARTNER_REGISTRATION and new process_step_types: + - SYNCHRONIZE_USER + - RETRIGGER_SYNCHRONIZE_USER + - TRIGGER_CALLBACK_OSP_SUBMITTED + - TRIGGER_CALLBACK_OSP_APPROVED + - TRIGGER_CALLBACK_OSP_DECLINED + - RETRIGGER_CALLBACK_OSP_SUBMITTED + - RETRIGGER_CALLBACK_OSP_APPROVED + - RETRIGGER_CALLBACK_OSP_DECLINED + + +Migration + +For each existing idp data set inside the table identity_providers; the following values will get set: +* idp owner +* idp type + +Logic: + +* all "KEYCLOAK_SHARED" IdPs got the idp type "3" set ("3" = "SHARED") +* all "KEYCLOAK_SHARED" IdP categories have been changed to "OIDC" +* "KEYCLOAK_OIDC" got renamed to "OIDC" +* "KEYCLOAK_SAML" got renamed to "SAML" +* all "OIDC" & "SAML" IdPs got the idp type "1" set ("1" = "owned") +* all "OIDC" and "SAML" IdPs need to have the "Customer" set as IdP owner + + +#### Enable Application Types - NEW - 1.7.0 + +The `company_applications` table has been expanded. New columns `company_application_type`, `onboarding_service_provider_id` have been added to have the possibility to track which onboarding service provider started an application for a specific company. + +image + +
+ +"onboarding_service_provider_id" => nullable +"external" => enum; 1 = "INTERNAL", 2 = "EXTERNAL" + +#### Enable Onboarding Service Provider - NEW 1.7.0 + +* NEW: portal.company_user_assigned_identity_providers +* NEW: portal.network_registrations +* NEW: portal.onboarding_service_provider_details +* EXTEND: portal.identity_user_statuses + +NEW portal.company_user_assigned_identity_providers table to be able to link a user to an identity provider +NEW portal.network_registrations to safe the network registrations of an onboarding service provider or operator +NEW portal.onboarding_service_provider_details to safe information of the onboarding service provider such as the auth_url to authenticate the technical users as well as the callback url +

@@ -256,10 +325,12 @@ New verified_credential_type_assigned_use_cases to map the verified_credential_t New verified_credential_external_types, verified_credential_external_type_use_case_detail_versions and verified_credential_type_assigned_external_types tables to have the versions for each type including the link from the verified_credential_external_types of a specific version to the verified_credential_types Company SSI Database Structure -![Company SSI Database Structure](/public/assets/images/docs/company-ssi-database.png) + +drawing Use Case Database Structure -![Use Case Database Structure](/public/assets/images/docs/use-case-database.png) + +drawing - NEW: table "language_long_names" - ENHANCED: table portal.languages "long_name_de" and "long_name_en" removed @@ -413,7 +484,7 @@ Attributes - service_type_id (connected to portal.service_types and replacing table service_assigned_service_types) - technical_user_needed (true/false flag) -image +image Impact on existing data: Migration script existing, based on the service type which is fetched for all existing data from portal table service_assigned_service_types, the technical_user_needed attribute is set to "true" for "DATASPACE_SERVICE" services and "false" for "CONSULTANCE_SERVICE". diff --git a/docs/static/CompanyApplicationTypes.png b/docs/static/CompanyApplicationTypes.png new file mode 100644 index 000000000..7dad2b361 Binary files /dev/null and b/docs/static/CompanyApplicationTypes.png differ diff --git a/docs/static/CompanySsiDatabase.png b/docs/static/CompanySsiDatabase.png new file mode 100644 index 000000000..beae1f36d Binary files /dev/null and b/docs/static/CompanySsiDatabase.png differ diff --git a/docs/static/IdentityProvidersUpdate.png b/docs/static/IdentityProvidersUpdate.png new file mode 100644 index 000000000..56996c600 Binary files /dev/null and b/docs/static/IdentityProvidersUpdate.png differ diff --git a/docs/static/ServiceDetails.png b/docs/static/ServiceDetails.png new file mode 100644 index 000000000..46840458e Binary files /dev/null and b/docs/static/ServiceDetails.png differ diff --git a/docs/static/company-ssi-database.png b/docs/static/company-ssi-database.png new file mode 100644 index 000000000..beae1f36d Binary files /dev/null and b/docs/static/company-ssi-database.png differ diff --git a/docs/static/use-case-database.png b/docs/static/use-case-database.png new file mode 100644 index 000000000..5b9fd67f8 Binary files /dev/null and b/docs/static/use-case-database.png differ diff --git a/package.json b/package.json index a6488b511..885aa2d76 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "cx-portal-assets", - "version": "v1.7.0-RC2", + "version": "v1.7.0-RC3", "description": "Shared frontend content and static assets for the Catena-X Portal", "main": "index.js", "repository": "git@github.com:eclipse-tractusx/portal-assets.git", diff --git a/public/assets/content/de/usecase.json b/public/assets/content/de/usecase.json index 94743ee1e..c70af894c 100644 --- a/public/assets/content/de/usecase.json +++ b/public/assets/content/de/usecase.json @@ -80,7 +80,7 @@ { "title": "Traceability unterteilt die Datenmodelle je Lebenszyklusphase", "description": "", - "imagePath": "/images/content/traceability_datamodels(en).svg", + "imagePath": "/images/content/traceability_datamodels(de).svg", "backgroundColor": "#FFFFFF", "id": "data-model-id", "images": ["/images/content/traceability_datamodels1(de).svg"], @@ -98,7 +98,7 @@ "title": "", "subTitles": [ "Im Beispiel fertigt ein KMU eine Charge von Zahnrädern mit der Chargennummer XX1235509 und der Sachnummer 5A52625. Nach Fertigung der Teile legt das KMU gemäß der Catena-X Standards für diese Charge mittels des Datenmodells Batch<0>Bildet Stammdaten einer Charge nach Verbau ab. Relevant für Hersteller von Bauteilen mit großen Losgrößen, die zu gleichen Herstellungsbedingungen produziert und in einer Chargennummer gebündelt werden. einen digitalen Zwilling in der Digital Twin Registry<0>Jedes rückverfolgbare Objekt wird über einen Digitalen Zwilling abgebildet und in der „Digital Twin Registry“ registriert. an. Darüber hinaus wird für die eindeutige Identifizierbarkeit im Catena-X Ökosystem eine Catena-X Unique-ID<0>Catena-X ID - Universally Unique Identifier (UUID): Jedes Objekt (Rohstoff, Bauteil od. Fahrzeug) erhält zur eindeutigen Identifikation im Catena-X Datenraum eine eindeutige Catena-X ID. für die Charge erzeugt. Dem Kunden wird über den EDC<0>Der Eclipse Dataspace Connector (EDC) ist der Standard-Konnektor im Netzwerk, der einen sicheren und souveränen Datenaustausch sicherstellt ein Datenangebot zum Abruf dieser Daten des Digitalen Zwillings zur Verfügung gestellt. Die physischen Bauteile (Zahnräder) werden anschließend an den Kunden verschickt.<1><1><1>", - "Der Kunde empfängt die Charge der Zahnräder des KMUs und scannt diese bei der Fertigung des Getriebes. Für das Getriebe (Seriennummer 21B294301258, Sachnummer 5A52479) erstellt er ebenfalls einen digitalen Zwilling und eine Catena-X Unique-ID. Für die Registrierung seines Digitalen Zwillings nutzt er das Datenmodell SerialPartTypization<0>Bildet Stammdaten eines Bauteils mit eigener Seriennummer nach Verbau ab. Relevant für Hersteller von lisierten Einzelteilen oder Fahrzeughersteller.. Die Informationen des Digitalen Zwilling stellt er über ein entsprechendes Datenangebot im EDC seinem Kunden, in diesem Fall dem OEM zur Verfügung. Für die logische Verknüpfung der beiden digitalen Zwillinge (Charge von Zahnrädern zu Getriebe) wird über einen Look-Up in der Digital Twin Registry die Catena-X Unique-ID der Charge ermittelt und mittels des Datenmodells AssemblyPartRelation<0>Bildet die Verbaubeziehungen zwischen den Bauteilen ab. Beispielsweise welche Charge (Zahnrad, Rohstoff) in welchem Serialisierten Teil (Getriebe) in welchem Fahrzeug verbaut ist. im digitalen Zwilling des Getriebes gespeichert. Durch diese logische Verknüpfung entsteht die Catena-X Datenkette.<1><1><1>", + "Der Kunde empfängt die Charge der Zahnräder des KMUs und scannt diese bei der Fertigung des Getriebes. Für das Getriebe (Seriennummer 21B294301258, Sachnummer 5A52479) erstellt er ebenfalls einen digitalen Zwilling und eine Catena-X Unique-ID. Für die Registrierung seines Digitalen Zwillings nutzt er das Datenmodell SerialPart<0>Bildet Stammdaten eines Bauteils mit eigener Seriennummer nach Verbau ab. Relevant für Hersteller von lisierten Einzelteilen oder Fahrzeughersteller.. Die Informationen des Digitalen Zwilling stellt er über ein entsprechendes Datenangebot im EDC seinem Kunden, in diesem Fall dem OEM zur Verfügung. Für die logische Verknüpfung der beiden digitalen Zwillinge (Charge von Zahnrädern zu Getriebe) wird über einen Look-Up in der Digital Twin Registry die Catena-X Unique-ID der Charge ermittelt und mittels des Datenmodells SingleLevelBoMAsBuilt<0>Bildet die Verbaubeziehungen zwischen den Bauteilen ab. Beispielsweise welche Charge (Zahnrad, Rohstoff) in welchem Serialisierten Teil (Getriebe) in welchem Fahrzeug verbaut ist. im digitalen Zwilling des Getriebes gespeichert. Durch diese logische Verknüpfung entsteht die Catena-X Datenkette.<1><1><1>", "Derselbe Prozess geschieht auf allen Ebenen, wie im obigen Beispiel auch zwischen Kunde und dem OEM.<1><1><1>" ], "id": "details3-id", @@ -106,7 +106,7 @@ "template": "TextCenterAlignedBody2" }, { - "title": "QUALITÄTSUNTERSUCHUNGEN UND WARNMELDUNGEN ENTLANG DER GESAMTEN LIEFERKETTE sind in den Apps über den Alerting-Prozess integriert.", + "title": "Qualitätsuntersuchungen und Warnmeldungen entlang der gesamten Lieferkette sind in den Apps über den Alerting-Prozess integriert", "description": "Für den Alerting-Prozess wurden Benachrichtigungen (Notifications) standardisiert. Diese sind Voraussetzung für die Interoperabilität verschiedener Apps im Rahmen des Alerting-Prozesses. Der Alerting-Prozess setzt sich aus Quality Investigations und Quality Alerts zusammen:", "imagePath": "/images/content/traceability_quality(de).png", "backgroundColor": "#F9F9F9", diff --git a/public/assets/content/en/usecase.json b/public/assets/content/en/usecase.json index 8c7b068ee..05555e7c4 100644 --- a/public/assets/content/en/usecase.json +++ b/public/assets/content/en/usecase.json @@ -83,7 +83,7 @@ "imagePath": "/images/content/traceability_datamodels(en).svg", "backgroundColor": "#FFFFFF", "id": "data-model-id", - "images": ["/images/content/traceability_datamodels1(de).svg"], + "images": ["/images/content/traceability_datamodels1(en).svg"], "template": "TextImageCenterAligned" }, { @@ -106,7 +106,7 @@ "template": "TextCenterAlignedBody2" }, { - "title": "QUALITY Investigations AND ALERTS ALONG THE ENTIRE SUPPLY CHAIN are integrated into the Apps via the alerting process.", + "title": "Quality Investigations and Alertings along the entire supply chain are integrated into the Apps via the alerting process", "description": "Notifications have been standardized for the alerting process. These are a prerequisite for the interoperability of various apps as part of the alerting process. The alerting process consists of Quality Investigations and Quality Alerts.", "imagePath": "/images/content/traceability_quality(en).png", "backgroundColor": "#F9F9F9", diff --git a/public/assets/images/content/traceability_datamodels1(de).svg b/public/assets/images/content/traceability_datamodels1(de).svg index 166a7562c..d79415dfd 100644 --- a/public/assets/images/content/traceability_datamodels1(de).svg +++ b/public/assets/images/content/traceability_datamodels1(de).svg @@ -17,7 +17,7 @@ - Lebenszyklus “as planned + Lebenszyklus “as planned" diff --git a/public/assets/images/content/traceability_datamodels1(en).svg b/public/assets/images/content/traceability_datamodels1(en).svg index 88b38b08b..056a9da45 100644 --- a/public/assets/images/content/traceability_datamodels1(en).svg +++ b/public/assets/images/content/traceability_datamodels1(en).svg @@ -17,7 +17,7 @@ - Lebenszyklus “as planned + Lebenszyklus “as planned"