Skip to content

VSN-1999 : Adapting importation , Individual saving & Update feature ,request/response DTOs and mappers on the new modification of School Class attributed (that changed from enum to db table).

yassine.elazami a demandé de fusionner VSN-1999 vers develop

Adapting Importation, Individual Saving & Update Feature, Request/Response DTOs and Mappers to the New School Class Model (Enum → Database Table)

Introduction

This merge request introduces a complete adaptation of the passenger importation, saving, updating, exporting, and administrative management pipelines following the major model change applied to the School Class attribute.
The School Class, previously represented as an enum, has been migrated to a fully managed database table.
This required adjustments to service layers, DTOs, mappers, import/export workflows, and the internal admin utility services.

The objective is to ensure smooth backward compatibility for prepared passengers, correct representation within request/response DTOs, and accurate mapping during both individual editing and bulk import/export scenarios. The changes aim to stabilize the transition while ensuring that future extensions of class-level metadata can be handled with minimal friction.


Overview of the Change

With the School Class no longer defined as an enum, the system can no longer rely on direct string-to-enum mapping. Instead, the class level must be resolved through a database lookup, using either the class level name or its UUID depending on the context.
This MR introduces a robust method set to support these lookups across all service layers.

This impacts:

  • Prepared passenger DTOs
  • Passenger entity mappers
  • Admin service and its implementation
  • Importation service logic
  • Export logic
  • Update flow for single passenger editing
  • The shared module version referenced in the project

Detailed Breakdown of Changes

1. Admin Service Enhancements

feat: Admin service

Introduced a new function signature dedicated to retrieving a class-level UUID based on a class-level name.
This is required during importation or DTO → entity conversion when the incoming data only contains the human-readable class name.

feat: Admin service implementation

Implemented the logic for fetching the class level UUID.
Ensures correct interaction with the database table storing school class levels.

refactor: Admin service

Added an additional method signature to retrieve the school class name based on its UUID.
This method is symmetrical with the previous one and is required by the export process.

feat: Admin service implementation (UUID → name)

Implemented the new method responsible for resolving the school class name from a UUID.
This supports the batch export process and ensures consistency across views.


2. DTO-Level Adjustments

feat: Prepared passenger DTO

Extended the Prepared Passenger DTO with two new fields:

  • classLevelCode (for readable display in UI components)
  • classLevelUuid (required during saving and updating operations)

These attributes provide the necessary data to maintain both user-friendly presentation and accurate persistence behavior.


3. Mapper and Entity Conversion Updates

refactor: Passenger mapper

Refactored the passenger mapper to remove the old enum-based direct mapping.
Now relies on the admin service to resolve class levels, using either class code or UUID depending on the incoming data.

refactor: Updating function

Adjusted the update flow to map the schoolClass field based on the newly submitted passenger object rather than the old DTO logic.
This ensures consistency with the database-backed model.


4. Importation Workflow Alignment

refactor: Importation service

Updated the CSV/Excel import handling to correctly resolve the school class via name-based lookup.
Replaced outdated enum mappings with calls to the admin service.


5. Export Process Adaptation

feat: Export passenger batch

Integrated the new admin service method to retrieve a class name from its UUID during export.
Ensures exported data includes the expected human-readable class code for external systems or reports.


6. Common Release Synchronization

feat: Pom file

Updated Maven dependencies to reference the latest common module release.
This ensures the shared DTO and domain components are aligned with the new database-driven class model.


7. Documentation and Maintenance

docs: Changelog

Updated the changelog to reflect the introduction of the new School Class handling mechanism and the related adjustments across services, DTOs, and batch processes.


Functional Impact

  • The system is now fully aligned with the new database-powered School Class model.
  • Import, update, save, and export flows all correctly map the School Class data using UUID and name resolution.
  • DTOs expose the needed properties to maintain both readable UI display and correct persistence.
  • Mappers are updated to avoid any reliance on deprecated enum logic.
  • Admin service now centralizes all class-level resolution logic, reducing duplication and improving maintainability.

Architectural Improvements

This MR introduces a cleaner architecture for class-level handling by:

  • Shifting all class resolution to a dedicated service layer
  • Removing hard-coded enum dependencies
  • Improving consistency in mapping across domains
  • Future-proofing the representation of School Class levels, enabling the introduction of additional metadata or relationships without further structural refactoring

Testing and Validation

The following scenarios were validated manually and through unit-level checks:

  • Prepared passenger saving and updating using UUID
  • Importation of passengers with class names in the source file
  • Exportation of passengers with correct class-level names
  • Conversion accuracy of DTOs and mappers
  • Admin service lookups for both UUID and class-level name
  • Consistency across different layers using the updated common module

Conclusion

This MR completes the migration of all passenger-related features toward the new School Class representation stored in the database.
The resulting structure is more robust, flexible, and maintainable, and it paves the way for future enhancements in school class management and associated educational metadata.

Closes VSN-1999

Modification effectuée par yassine.elazami

Rapports de requête de fusion