Registration & Portal: Frontend Repositories Merge and App Update

[jjeroch]

Overview

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.

Goals

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.

Scope

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.

Acceptance Criteria

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

Risks and Mitigations

• 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.

Dependencies

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

[stephanbcbauer]

Was presented in the open planning ⇾ done internally within in the portal team

[stephanbcbauer]

Hello @jjeroch , @evegufy

Since the feature is a 24.08 feature and the development phase is coming to an end, we need a status on the feature.

• [ ] 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 check whether there is an assignment to a committee or expert group (supported-by) to be found on the board
• [ ] 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.

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

[stephanbcbauer]

Hello @jjeroch, @evegufy,

In a few weeks, we want to publish Tractus-X Release 24.08. For this, we need a clear status about the features (which will be included in the release and which will be cancelled or postponed to the next release).

Currently, the feature is still in status Backlog. Please update the status by 09.07.24 eob.

If the feature is not ready for release 24.08, or it is possibly not planned at all, please set the status to Not in release. Please remember that in this case, any dependent components must be informed.

Thank you and best regards.

[MaximilianHauer]

As internally aligned we did remove this feature from the scheduled release 24.08. Reschedule will be for 24.12. Milestone will be updated to 24.12. in open planning