Registration & Portal: Frontend Repositories Merge and App Update

[MaximilianHauer]

Overview

Explain the topic in 2 sentences

This feature aims to consolidate the registration frontend repository with the portal frontend repository to streamline development and maintenance processes. Additionally, the registration application will be updated to utilize the shared-component library for design consistency. Special attention will be given to ensure that the integration does not negatively impact the portal codebase.

What's the benefit?

What are the Risks/Dependencies ?

Integration Complexity: The merge could introduce complex integration issues. This will be mitigated by thorough planning and testing before the merge. Design Inconsistency: There is a risk that some design elements may not align perfectly with the shared-component library. This will be mitigated by a detailed design review and testing. Code Compatibility: The newer code stack of the registration app may cause compatibility issues. This will be mitigated by careful code review and testing, with fallback plans in place.

• no external dependencies interfaces on registration app are outbound oriented, those will not change

Detailed explanation

Current implementation

• currently registration and portal frontend are seperate repositories .
• registration is not using the shared-components repo as a design guideline

Proposed improvements

Repository Merge

Codebase Integration: The registration and portal repositories will be merged into a single repository. The merge will be carefully planned to preserve the commit history of both repositories. Build Process: The build process will be updated to accommodate both applications within the same repository. This includes scripts, dependencies, and any continuous integration configurations.

Registration App Update

Shared-Component Library Integration: The registration application will be refactored to use the shared-component library, ensuring design consistency across the platform. Design Element Update: All design elements within the registration app will be reviewed and updated to align with the shared-component library's standards.

Code Stack Compatibility

Translation Files: The translation files for the registration and portal applications will be kept separate to maintain clear localization boundaries. Linter Configuration: Linters that are failing for the registration path will be selectively disabled to ensure they do not affect the portal code. The linter configuration will be carefully documented to explain the exceptions. Code Review: A thorough code review will be conducted to identify any potential conflicts or issues arising from the merge, particularly focusing on the newer code stack of the registration app.

URL and Permission Cleanup

URLs Review: All registration path URLs will be audited to ensure they are structured logically and consistently with the portal's URL schema. Permission Configuration: The permission configurations for the registration app will be reviewed and cleaned up to ensure they are accurate and secure. Cleanup Process: Any redundant, outdated, or conflicting settings related to the registration path will be identified and resolved.

Feature Team

Contributor

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

Committer

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

User Stories

Userstories to be created

1. Merge the registration frontend repository with the portal frontend repository.
2. Update based on the merge the build/pipeline processes and helm chart setup
3. Update the registration application to use the shared-component library for design elements.
4. Ensure the registration app's later code stack does not negatively interfere with the portal code.
5. Maintain separate translation files for each application.
6. Disable failing linters specifically for the registration path to avoid disruption.
7. Review and clean up registration path URLs, permission configurations, and similar settings.

Acceptance Criteria

• [ ] Successful Merge: The registration and portal frontend repositories are merged without loss of functionality or data.
• [ ] Design Consistency: The registration app uses the shared-component library and aligns with the overall design language of the platform.
• [ ] Separate Translations: Translation files for the registration and portal apps remain separate and functional.
• [ ] Linter Compatibility: The portal code remains unaffected by the disabled linters for the registration path, and the reasons for disabling are well documented.
• [ ] Clean URLs and Permissions: The registration path URLs and permission configurations are logical, consistent, and secure after the cleanup.

Test Cases

TestCase for "Successful Merge"

Description To verify that after merging the registration and portal frontend repositories, both functionalities and data remain intact and operational.

Steps

1. Perform a merge operation of the registration and portal frontend repositories.
2. Deploy the merged application to a testing environment.
3. Access the registration functionality and complete the registration process.
4. Access the various functionalities of the portal that existed before the merge.
5. Validate that all data from both repositories is present and accounted for.

Expected Results

• The merge operation completes without errors.
• The merged application deploys successfully.
• The registration process works as expected without any errors or loss of functionality.
• All pre-existing functionalities of the portal work as before without any errors or loss of functionality.
• No data is lost or corrupted as a result of the merge.

TestCase for "Design Consistency"

Description To ensure that the registration application utilizes the shared-component library and adheres to the platform's design language.

Steps

1. Navigate through all the screens of the registration application.
2. Check for the usage of shared components in the registration app's interface.
3. Compare the design elements of the registration app with the platform's overall design language.

Expected Results

• All screens in the registration app are accessible and render correctly.
• Shared components from the library are used consistently across the registration app.
• The design of the registration app matches the platform's design language in terms of color schemes, fonts, button styles, and other UI elements.

TestCase for "Separate Translations"

Description To validate that translation files for the registration and portal apps remain separate, functional, and do not interfere with each other post-merge.

Steps

1. Locate the translation files for both the registration and portal apps in the repository.
2. Make changes to the translation files of the registration app and deploy the changes.
3. Test the registration app in different languages to ensure translations are applied correctly.
4. Repeat the process for the portal app and verify that its translations are working as intended.

5. Expected Results

• Translation files for both apps are separate and identifiable.
• Changes to the registration app's translations do not affect the portal app's translations.
• The registration app correctly displays translations for all supported languages.
• The portal app correctly displays translations for all supported languages, independent of the registration app's translations.

TestCase for "Clean URLs and Permissions"

Description To ensure that after the cleanup, registration path URLs and permission configurations are logical, consistent, and secure.

Steps

1. Review the list of URLs associated with the registration path to ensure they follow a logical and consistent naming convention.
2. Test each URL to confirm that it leads to the correct page or functionality within the registration process.
3. Verify that all URLs have the appropriate permission checks in place and are not accessible by unauthorized users.
4. Conduct security tests to check for vulnerabilities such as broken access control or improper redirects.

Expected Results

• URLs for the registration path are structured logically and follow a consistent naming convention.
• Each URL directs to the appropriate page or function without any errors.
• Permission configurations for each URL are correct, allowing access only to authorized users and roles.
• Security tests reveal no vulnerabilities, confirming that URLs and permissions are secure post-cleanup.

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]

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

• Please add assignee (overall responsible person who drives the feature)