Story QR-001 : Squelette du module + Infrastructure de test +¶

@assignee: @m-kouassi

Module d'événements partagés : qr-attendance
Tranche : QR-T0-001 + QR-T0-003.
Contexte de marque : [LES DEUX] Papillon HR Suite + ALTARYS ENTERPRISE HR Suite.
Priorité : 1.
Dépend de : Plan de contrôle (TenantContext, gating des modules).
Peut être développé en parallèle avec : Aucun.
Ordre de fusion : Avant toutes les autres stories QR.
Complexité estimée : S.
PRD User Stories : N/A — Story technique.

Objectif¶

Créer la structure du module Spring Modulith com.altarys.papillon.modules.attendance : - ajouter les dépendances requises (ZXing pour la génération de QR, Apache POI pour l'exportation vers Excel), - mettre en place l'infrastructure de test (TestContainers, beans de simulation, fixtures de test) - et définir des contrats d'événements partagés pour la communication inter-modules. Il s'agit de la base sur laquelle s'appuieront toutes les stories QR-attendance suivantes.

Portée du backend¶

Entités et enregistrements¶

Enregistrements d'événements partagés (dans com.altarys.papillon.events.attendance) :

// AttendanceRecorded.java
public record AttendanceRecorded(
    UUID tenantId,
    UUID employeeId,
    LocalDate attendanceDate,
    String status,          // PRESENT, RETARD, ABSENT, etc.
    int workedMinutes,
    int overtimeMinutes,
    OffsetDateTime recordedAt
) {}

// WeeklyOvertimeComputed.java
public record WeeklyOvertimeComputed(
    UUID tenantId,
    UUID employeeId,
    LocalDate weekStartDate,
    LocalDate weekEndDate,
    int totalWorkedMinutes,
    int band1Minutes,
    int band2Minutes,
    int band3Minutes,
    int nightMinutes,
    int sundayHolidayMinutes,
    int totalOvertimeMinutes,
    OffsetDateTime computedAt
) {}

Enregistrement d'événement partagé

(dans com.altarys.papillon.events.holiday) :

// PublicHolidayUpdated.java
public record PublicHolidayUpdated(
    String countryCode,
    int year,
    OffsetDateTime updatedAt
) {}

Migrations Flyway¶

Aucune — cette entité ne crée aucune table de base de données.

Couche de repository¶

Aucune.

Couche de service¶

Aucune — uniquement la structure des paquets et la configuration.

Endpoints API¶

Aucun.

Règles de validation¶

Aucune.

Considérations relatives à la multi-location¶

La classe de configuration du module doit déclarer la limite du module de présence pour Spring Modulith. Tous les futurs services au sein de ce module accèdent au contexte de tenant via TenantContextHolder.current().

Portée du front-end¶

Aucune — facilitateur technique, backend uniquement.

Critères d'acceptation¶

AC-001: Module compiles and Spring Modulith verifies module boundaries
Given the attendance module package structure is created
When the application starts with `./gradlew bootRun`
Then Spring Modulith detects the attendance module without boundary violations
And the module is registered as an Application Plane module

AC-002: Test infrastructure runs successfully
Given TestContainers is configured for attendance tests
When `./gradlew test` is executed
Then the AttendanceModuleIntegrationTest passes
And shared event records can be instantiated and serialized

¶

OHADA et règles réglementaires¶

Aucune pour cette épicopée technique.

Normes et conventions¶

docs/standards/java-spring-guidelines.md — Structure des paquets, conventions Spring Modulith
docs/standards/database-guidelines.md — Modèles de conception multi-tenant (référencé pour les épicopées futures)

Exigences de test¶

Tests unitaires¶

Vérifier que tous les enregistrements d'événements partagés peuvent être instanciés avec des données valides
Vérifier la sérialisation/désérialisation des enregistrements d'événements (aller-retour JSON)

Tests d'intégration¶

AttendanceModuleIntegrationTest : le contexte Spring se charge avec le module de présence
Test de vérification des limites du module Spring Modulith
TestContainers PostgreSQL démarre et est accessible

Ce que l'assurance qualité va valider¶

Sans objet (aucune fonctionnalité destinée aux utilisateurs).

Hors du périmètre¶

Pas de tables de base de données (chaque story crée ses propres tables)
Pas d’endpoints API
Pas de code front-end
Pas de logique métier
[ ] Dépendance ZXing ajoutée à backend/build.gradle
[ ] Dépendance Apache POI ajoutée à backend/build.gradle
[ ] Enregistrements d'événements partagés créés dans com.altarys.papillon.events.attendance et com.altarys.papillon.events.holiday
[ ] AttendanceModuleIntegrationTest réussi
[ ] Classe d'aide AttendanceTestFixtures créée
[ ] La vérification des limites Spring Modulith réussit
[ ] ./gradlew test est vert
[ ] ./gradlew spotlessApply réussit