Merge pull request #194 from eclipse-tractusx/merge/v1.7.0-RC3

release(1.7.0-RC3): merge release into main

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

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
 
+<br>
+
+#### 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.
+
+<img width="779" alt="image" src="/docs/static/IdentityProvidersUpdate.png">
+
+- 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.
+
+<img width="427" alt="image" src="/docs/static/CompanyApplicationTypes.png">
+
+<br>
+
+"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
+
 <br>
 <br>
 
@@ -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)
+
+<img src="/docs/static/company-ssi-database.png" alt="drawing" width="900"/>
 
 Use Case Database Structure
-![Use Case Database Structure](/public/assets/images/docs/use-case-database.png)
+
+<img src="/docs/static/use-case-database.png" alt="drawing" width="600"/>
 
 - 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)
 
-<img width="376" alt="image" src="https://user-images.githubusercontent.com/94133633/228341713-1bbc0354-0ebf-42f7-bc37-135567037b60.png">
+<img width="376" alt="image" src="/docs/static/ServiceDetails.png">
 
 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".

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": "[email protected]:eclipse-tractusx/portal-assets.git",

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,15 +98,15 @@
         "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 <strong class='tooltip'>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.</0></strong> einen digitalen Zwilling in der <strong class='tooltip'>Digital Twin Registry<0>Jedes rückverfolgbare Objekt wird über einen Digitalen Zwilling abgebildet und in der „Digital Twin Registry“ registriert.</0></strong> an. Darüber hinaus wird für die eindeutige Identifizierbarkeit im Catena-X Ökosystem eine <strong class='tooltip'>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.</0></strong> für die Charge erzeugt. Dem Kunden wird über den  <strong class='tooltip'>EDC<0>Der Eclipse Dataspace Connector (EDC) ist der Standard-Konnektor im Netzwerk, der einen sicheren und souveränen Datenaustausch sicherstellt</0></strong> 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></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 <strong class='tooltip'>SerialPartTypization<0>Bildet Stammdaten eines Bauteils mit eigener Seriennummer nach Verbau ab. Relevant für Hersteller von lisierten Einzelteilen oder Fahrzeughersteller.</0></strong>. 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 <strong class='tooltip'>AssemblyPartRelation<0>Bildet die Verbaubeziehungen zwischen den Bauteilen ab. Beispielsweise welche Charge (Zahnrad, Rohstoff) in welchem Serialisierten Teil (Getriebe) in welchem Fahrzeug verbaut ist.</0></strong> im digitalen Zwilling des Getriebes gespeichert. Durch diese logische Verknüpfung entsteht die Catena-X Datenkette.<1></1><1></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 <strong class='tooltip'>SerialPart<0>Bildet Stammdaten eines Bauteils mit eigener Seriennummer nach Verbau ab. Relevant für Hersteller von lisierten Einzelteilen oder Fahrzeughersteller.</0></strong>. 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 <strong class='tooltip'>SingleLevelBoMAsBuilt<0>Bildet die Verbaubeziehungen zwischen den Bauteilen ab. Beispielsweise welche Charge (Zahnrad, Rohstoff) in welchem Serialisierten Teil (Getriebe) in welchem Fahrzeug verbaut ist.</0></strong> im digitalen Zwilling des Getriebes gespeichert. Durch diese logische Verknüpfung entsteht die Catena-X Datenkette.<1></1><1></1><1></1>",
           "Derselbe Prozess geschieht auf allen Ebenen, wie im obigen Beispiel auch zwischen Kunde und dem OEM.<1></1><1></1><1></1>"
         ],
         "id": "details3-id",
         "backgroundColor": "#f9f9f9",
         "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",

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",