Reprise après refus – backend #111
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Objectif (alignement workflow produit)
Après refus par le gestionnaire (message + e-mail, cf. #110), le parent ou l'AM doit pouvoir reprendre son dossier soit via le lien dans le mail (token), soit depuis la page de connexion (saisie numéro de dossier + e-mail).
Une fois identifié·e, l'utilisateur entre dans le même parcours d'inscription (parent ou AM selon le rôle), déjà prérempli avec les données du dossier refusé, corrige ce qui doit l'être, valide jusqu'au bout, puis le dossier retombe en « à valider » (
en_attente) pour le gestionnaire.Périmètre backend (#111)
Identification
POST /auth/reprise-identify:numero_dossier+email→type(parent|assistante_maternelle) +token(lien perdu, entrée login).GET /auth/reprise-dossier?token=: retourner un jeu de données suffisant pour préremplir tout le parcours d'inscription (équivalent métier à ce qui est collecté à la création : identité, coordonnées, pièces / consentements pertinents, enfants pour le parcours parent, champs AM pour le parcours AM, etc. — à cadrer avec les DTO d'inscription existants).Resoumission
register/parentetregister/amen mode reprise, ou un endpoint dédié équivalent qui :en_attente;token_reprise/token_reprise_expire_le.Cohérence données — numéro de dossier
reprise-identify, lenumero_dossierdoit être déjà connu côté dossier (affectation gestionnaire avant ou au refus, selon règle métier) ; sinon message d'erreur explicite côté API / spec.numero_dossierest à conserver tel quel pendant toute la reprise — pas de nouvelle attribution, pas de modification par le parcours utilisateur ; c'est l'ancre stable du dossier refusé jusqu'à la nouvelle validation gestionnaire (y compris cohérence surutilisateurs,parents,assistantes_maternellessi applicable).Sécurité / anti-énumération (optionnel mais souhaitable)
Hors périmètre
Dépendances
Critères de done (backend)
GET reprise-dossierexpose les données nécessaires au préremplissage complet du parcours parent ou AM (spec jointe aux DTO).en_attente, token reprise consommé, dossier visible dans la file de vérification gestionnaire.numero_dossierreste strictement inchangé sur tout le flux (chargement → corrections → resoumission) ; tests de non-régression.reprise-identify+reprise-dossier+ resoumission documentés (OpenAPI) et couverts par tests ciblés.Issue mise à jour pour être alignée avec le workflow « refus → mail ou login (n° + e-mail) → parcours inscription prérempli → nouvelle validation gestionnaire ».
Note d'implémentation (architecture)
mode+ nombreuxValidateIf), tout en réutilisant les sous-DTO imbriqués (enfants, co-parent, etc.) pour limiter le doublon.applyParentDossier(dto, context)/ équivalent AM, oùcontextporte création vs reprise, leEntityManagertransactionnel, identifiants existants,numero_dossierinchangé en reprise, invalidationtoken_reprise, etc.Livré : GET /auth/reprise-dossier?token= (dossier pour préremplir), PATCH /auth/reprise-resoumettre (token + champs → en_attente, token invalidé), POST /auth/reprise-identify (numero_dossier + email → type + token).
Description #111 mise à jour : périmètre backend = parcours inscription complet (préremplissage + resoumission équivalente création), aligné avec le workflow produit et #112.
Précision ajoutée : conserver le
numero_dossiertout au long de la reprise (pas de régénération / pas de changement côté parcours utilisateur) + critère de done associé.Alignement #111 : ajout section Note d’implémentation — 2 DTO (création / reprise) + / équivalent AM + front = 2 endpoints selon contexte (cf. #112).