Better Support of Company Short Names

[ybidois]

Overview

Explain the topic in 2 sentences

The Portal registration flow and its overall UX and UI must be compatible with our customers' legal and short names.

What's the benefit?

Allow all customers to register smoothly with both their legal names and identifiers:

• Have legal name used only where it is needed
• Use short name everywhere else
• Great UX/UI integration

What are the Risks/Dependencies ?

• BPDM
• Wallet
• Gaia-X Clearing House

Detailed explanation

Current implementation

• Legal name used everywhere

Proposed improvements

• Customer registration:
  • Allow the use of any legal name based on country specificity
  • Allow the choice of a short name with limited characters
• Use the brand name in all subsequent fields, unless the legal name is required
• Where the legal name is required, adjust the UI
• Where the short name can be used, adjust the UI

Feature Team

Contributor

• @Cofinity-UX
• @typecastcloud
• @ybidois
• @dhiren-singh-007

Committer

• @oyo
• @ntruchsess
• @Phil91
• @evegufy

Issues

eclipse-tractusx/portal-frontend#993
eclipse-tractusx/portal-frontend#1007

User Stories

• Provider view for the connector which is provided by provider company to customer/host company portal-backend#1087

Acceptance Criteria

• Portal should support countries as per the Catena-X official White List (+ Yellow List under certain conditions).
• 100% of all legal names in the countries we officially support are accepted in the registration process
  • Very long names
  • Country-specific with unique characters
• Legal names are used only where required, brand names are otherwise used
• OSP functionality should also comply with the defined requirements

Test Cases

• For each supported country, successful registration of an edge case legal name (very long or special characters) + identifier
• Short names are used and displayed across:
  • Registration process
  • User invitation process
  • Company detail pages
  • App release process
  • Service release process

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

• This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
    • CX-0010 Business Partner Number
    • CX-0013 Identity of Member Companies
    • CX-0018 Data Space Connectivity (EDC)
    • CX-0049 DID Document Schema
    • CX-0050 Framework Agreement Credential
    • CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
    • CX-0001 EDC Discovery API
    • CX-0002 Digital Twins in Catena-X
    • CX-0018 Data Space Connectivity (EDC)
  • Data Format:
    • The data model is based on a published Semantic Model
• The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

Additional information

• I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

[stephanbcbauer]

@ybidois not sure about this feature. Is it planned to present it in tomorrow's planning? It was never presented in a Refinement meeting. Did we miss something?

[Sebastian-Wurm]

• Regarding identifier types, we have an overlap with Harmonization and Enhancement of identifier types #605. Let's work together here.
  • We probably want to store the REGEX in BPDM rather than in the Portal. @nicoprow: Please confirm.
  • Regarding GXDCH identifier types, there is a first implementation proposal for portal-backend here: Add new BPDM identifier types portal-backend#895
• Regarding "brand name": please use the term "short name" from BPDM as defined in CX-0012.

[nicoprow]

• Regarding identifier types, we have an overlap with Harmonization and Enhancement of identifier types #605. Let's work together here.

  * We probably want to store the REGEX in BPDM rather than in the Portal. @nicoprow: Please confirm.
  * Regarding GXDCH identifier types, there is a first implementation proposal for portal-backend here: [Add new BPDM identifier types portal-backend#895](https://github.com/eclipse-tractusx/portal-backend/issues/895)
  

  • Regarding "brand name": please use the term "short name" from BPDM as defined in CX-0012.

Any validation on the identifier types eventually also needs to be performed in the Pool. Yea we will need to align on the REGEX and we can also make it available over the BPDM API to reduce duplication and reduce the risk of mismatched validations.

[ybidois]

Hi @Sebastian-Wurm, @nicoprow, I agree with what you propose:

• Using the short name → I updated the feature description accordingly
• Aligning on REGEX, storing in BPDM, and making it available over BPDM API
  It will reduce a lot of errors on all sides.

Let me check with @evegufy and the Open-Source Portal team the best way to work together on this and we will get back to you.

[ybidois]

As discussed with @evegufy, we will bring our changes in 25.03 instead!

[ybidois]

Updated with new template

[typecastcloud]

The scope feels very different for short name + identifier changes.

1. Short name UX/UI adjustments with clear REGEX to limit length and characters
2. Identifier validation in general and especially with dependency to BPDM validation

Maybe a bit late to split up.

Was there already some refinement on what methods BPDM team wants to provide?

[ybidois]

I don't think it's too late to split the scope. We could keep this one for names as names extend beyond the registration process and have identifiers as part of the Registration Process Improvements here → #966.

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Please add missing sections from the feature template, or fill them out
• Please add committer

[evegufy]

Committers:
@oyo
@ntruchsess
@Phil91
@evegufy