[Backend] Harmoniser API cr�ation administrateur avec le contrat frontend #97

New Issue

jmartin · 2026-02-24T09:37:10Z

jmartin commented

2026-02-24 09:37:10 +00:00

Contexte

Le frontend avance sur la cr�ation d'administrateur via modale (ticket #96) avec un contrat minimal similaire � la cr�ation gestionnaire.
Actuellement, POST /api/v1/users impose des champs h�rit�s de CreateUserDto qui ne sont pas pertinents pour ce flux (ex: certains champs m�tier non n�cessaires).

Objectif

Rendre l'API de cr�ation administrateur coh�rente et stable avec le besoin frontend, en d�finissant un contrat clair et minimal.

Contrat API attendu (obligatoire)

Champs autoris�s / attendus

nom
prenom
email
password
telephone

Champs qui ne doivent pas �tre requis pour ce flux

adresse
ville
code_postal
situation_familiale
photo_url
consentement_photo
date_consentement_photo
changement_mdp_obligatoire
cguAccepted

R�gle r�le

role ne doit pas venir du frontend
le backend fixe automatiquement role = administrateur

Exemple payload frontend

{
  "nom": "Dupont",
  "prenom": "Claire",
  "email": "claire.dupont@example.com",
  "password": "MonMdpFort123",
  "telephone": "0612345678"
}

Travail attendu

Introduire un DTO d�di� � la cr�ation d'administrateur (ex: CreateAdministrateurDto)
Appliquer exactement le contrat ci-dessus
Garantir le comportement s�curit� actuel (acc�s super_admin uniquement)
Retour API coh�rent avec les autres endpoints user

Crit�res d'acceptation

Un appel POST de cr�ation administrateur avec seulement les 5 champs minimaux r�ussit
Aucun champ hors p�rim�tre n'est requis
Le r�le cr�� est bien administrateur
Les validations restent strictes (email, mot de passe, etc.)
Pas de r�gression sur la cr�ation d'autres profils

R�f�rences

Ticket frontend: #96
Ticket frontend gestionnaire: #35

## Contexte Le frontend avance sur la cr�ation d'administrateur via modale (ticket #96) avec un contrat minimal similaire � la cr�ation gestionnaire. Actuellement, `POST /api/v1/users` impose des champs h�rit�s de `CreateUserDto` qui ne sont pas pertinents pour ce flux (ex: certains champs m�tier non n�cessaires). ## Objectif Rendre l'API de cr�ation administrateur coh�rente et stable avec le besoin frontend, en d�finissant un contrat clair et minimal. ## Contrat API attendu (obligatoire) ### Champs autoris�s / attendus - `nom` - `prenom` - `email` - `password` - `telephone` ### Champs qui ne doivent pas �tre requis pour ce flux - `adresse` - `ville` - `code_postal` - `situation_familiale` - `photo_url` - `consentement_photo` - `date_consentement_photo` - `changement_mdp_obligatoire` - `cguAccepted` ### R�gle r�le - `role` ne doit pas venir du frontend - le backend fixe automatiquement `role = administrateur` ### Exemple payload frontend ```json { "nom": "Dupont", "prenom": "Claire", "email": "claire.dupont@example.com", "password": "MonMdpFort123", "telephone": "0612345678" } ``` ## Travail attendu - Introduire un DTO d�di� � la cr�ation d'administrateur (ex: `CreateAdministrateurDto`) - Appliquer exactement le contrat ci-dessus - Garantir le comportement s�curit� actuel (acc�s super_admin uniquement) - Retour API coh�rent avec les autres endpoints user ## Crit�res d'acceptation - Un appel `POST` de cr�ation administrateur avec seulement les 5 champs minimaux r�ussit - Aucun champ hors p�rim�tre n'est requis - Le r�le cr�� est bien `administrateur` - Les validations restent strictes (email, mot de passe, etc.) - Pas de r�gression sur la cr�ation d'autres profils ## R�f�rences - Ticket frontend: #96 - Ticket frontend gestionnaire: #35

jmartin referenced this issue from a commit

2026-02-24 10:04:03 +00:00

feat(backend): implement create admin API (ticket #97)

jmartin closed this issue

2026-02-24 10:04:11 +00:00

jmartin referenced this issue from a commit

2026-02-24 10:04:24 +00:00

docs: close ticket #97

Sign in to join this conversation.