Compare commits

...
Author SHA1 Message Date
jmartinandCursor 7d491d5072 docs: norme merge squash (feature→develop→master).
Met à jour la décision §26, le briefing front et l’API Gitea.
Les merges --no-ff déjà poussés (#167/#168) restent inchangés.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:55:55 +02:00
jmartin f9fd8d73a8 Merge branch 'feature/168-api-couples-garde-parent' into develop
Closes #168 — API couples de garde parent.
2026-09-24 00:53:38 +02:00
jmartinandCursor 93ee3a5549 fix(#168): typage colonne placement garde courant compatible TypeORM.
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:51:06 +02:00
jmartinandCursor db08aca714 feat(#168): API couples de garde parent (liste + couple courant).
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:51:05 +02:00
jmartin 494f0e4c19 Merge branch 'feature/167-selecteur-couple-enfant-nounou' into develop 2026-09-24 00:47:10 +02:00
jmartinandCursor 9a4664a8ea fix(ui): align right tile by reserving chevron space
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:45:01 +02:00
jmartinandCursor bf00933f65 fix(ui): use pencil line asset for separation in CoupleSelectorBandeau
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:43:16 +02:00
jmartinandCursor 7b4650b81b fix(ui): show only first name and increase font size to 22 in CoupleSelectorBandeau
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:41:32 +02:00
jmartinandCursor b7ae07f5aa fix(ui): increase font size for names in CoupleSelectorBandeau
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:39:20 +02:00
jmartinandCursor a88f791317 fix(ui): increase avatar size in CoupleSelectorBandeau
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:38:32 +02:00
jmartinandCursor 138398a4a0 fix(ui): remove opacity on dropdown items and assign unique bandeau colors by index
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:35:52 +02:00
jmartin 7cf30643aa Merge branch 'feature/167-selecteur-couple-enfant-nounou' into develop 2026-09-24 00:33:12 +02:00
jmartinandCursor 5eb3468fe0 fix(ui): prevent dropdown menu from overlapping main button in CoupleSelectorBandeau
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:33:02 +02:00
jmartinandCursor df4f48e864 feat(front): selecteur couple enfant-nounou (#167)
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-24 00:12:10 +02:00
jmartin 6f9136aae5 Merge branch 'feature/166-tdb-parent-coquille-bandeau' into develop (#166) 2026-09-23 23:39:56 +02:00
jmartinandCursor 461c70df05 refactor(front): suppression anciens widgets dashbord_parent remplaces par la coquille quotidien (#166)
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-23 23:39:08 +02:00
jmartinandCursor fa88d00657 chore(assets): pastille corail en reserve (#166)
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-23 23:36:06 +02:00
jmartinandCursor 6e18956a63 feat(front): coquille quotidien parent 3 colonnes + bandeau pastel (#166)
- QuotidienShell / QuotidienBandeau / QuotidienTheme reutilisables (parent, AM #169)
- Bandeau : logo, pastilles dessinees Cahier de liaison / Agenda / Contrat
  (jaune / peche / turquoise, inactive = meme couleur a 45 %), menu user sur
  pastille lavande
- Separateurs trait crayon gris (bandeau / colonnes / footer)
- ImageButton : shape stadium (focus suit le contour) + bgOpacity
- AppFooter : option showTopBorder
- ParentDashboardScreen branche sur la coquille avec placeholders
  cartes (#167/#173), blog (#178), messagerie (#184), stubs Agenda/Contrat (#187)
- Assets pastilles (meme silhouette 1190x299) et traits crayon

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-23 23:34:36 +02:00
jmartinandCursor 745349bc83 docs(0.2.0): mini-spec quotidien parent/AM, découpage tickets et maquettes.
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-23 17:17:15 +02:00
jmartinandCursor 89f65356d1 docs(#117): CDC V1.4 (users à jour, reste conservé) + SRS utilisateurs.
- CDC complet conservé ; sections gestion utilisateurs / dossiers alignées v0.1.0
- Archive V1.3 + EVOLUTIONS_CDC ; nouvelle 12_SRS-GESTION-UTILISATEURS
- INDEX / versions / bilan mis à jour

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-15 10:22:32 +02:00
jmartinandCursor 71b1897678 docs: rationalisation post-0.1.0 (bilan, purge tmp, archives).
- Bilan 29 + index versions 05 ; suivi tickets pointeur Gitea
- Purge docs/tmp et archive/temporaires livrés
- Archive SuperNounou, liste tickets figée, backlog Phase 2, notes 14/92
- Suppression stubs PROCEDURE/22 ; INDEX et roadmap alignés

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-14 17:45:43 +02:00
jmartin 3218daa12e merge(#164): uniformisation modale staff gestionnaire / admin. 2026-09-14 17:29:31 +02:00
90 changed files with 4273 additions and 2947 deletions
+12
View File
@@ -5,6 +5,7 @@ import {
import { Users } from './users.entity'; import { Users } from './users.entity';
import { ParentsChildren } from './parents_children.entity'; import { ParentsChildren } from './parents_children.entity';
import { Dossier } from './dossiers.entity'; import { Dossier } from './dossiers.entity';
import { AmChildren } from './am_children.entity';
@Entity('parents', { schema: 'public' }) @Entity('parents', { schema: 'public' })
export class Parents { export class Parents {
@@ -25,6 +26,17 @@ export class Parents {
@Column({ name: 'numero_dossier', length: 20, nullable: true }) @Column({ name: 'numero_dossier', length: 20, nullable: true })
numero_dossier?: string; numero_dossier?: string;
/**
* Placement AM↔enfant sélectionné sur le TdB parent (couple actif) — ticket #168.
* Null / absent = le front prend le premier couple actif retourné par lAPI.
*/
@Column({ name: 'id_placement_garde_courant', type: 'uuid', nullable: true })
id_placement_garde_courant?: string;
@ManyToOne(() => AmChildren, { nullable: true, onDelete: 'SET NULL' })
@JoinColumn({ name: 'id_placement_garde_courant', referencedColumnName: 'id' })
placement_garde_courant?: AmChildren;
// Lien vers enfants via la table enfants_parents // Lien vers enfants via la table enfants_parents
@OneToMany(() => ParentsChildren, pc => pc.parent) @OneToMany(() => ParentsChildren, pc => pc.parent)
parentChildren: ParentsChildren[]; parentChildren: ParentsChildren[];
@@ -0,0 +1,61 @@
import { ApiProperty, ApiPropertyOptional } from '@nestjs/swagger';
/** Identité minimale enfant pour le bandeau couple — ticket #168 */
export class CoupleGardeEnfantDto {
@ApiProperty({ format: 'uuid' })
id: string;
@ApiPropertyOptional()
prenom?: string | null;
@ApiPropertyOptional()
nom?: string | null;
@ApiPropertyOptional()
photo_url?: string | null;
}
/** Identité minimale AM pour le bandeau couple — ticket #168 */
export class CoupleGardeAmDto {
@ApiProperty({ format: 'uuid', description: 'UUID utilisateur de lAM' })
id: string;
@ApiPropertyOptional()
prenom?: string | null;
@ApiPropertyOptional()
nom?: string | null;
@ApiPropertyOptional()
photo_url?: string | null;
}
/** Un couple de garde = placement actif enfant ↔ AM */
export class CoupleGardeDto {
@ApiProperty({
format: 'uuid',
description: 'Id du placement (enfants_assistantes_maternelles.id)',
})
id: string;
@ApiProperty({ type: CoupleGardeEnfantDto })
enfant: CoupleGardeEnfantDto;
@ApiProperty({ type: CoupleGardeAmDto })
am: CoupleGardeAmDto;
@ApiProperty({ description: 'True si cest le couple actuellement sélectionné' })
courant: boolean;
}
export class CouplesGardeResponseDto {
@ApiProperty({ type: [CoupleGardeDto] })
couples: CoupleGardeDto[];
@ApiPropertyOptional({
format: 'uuid',
nullable: true,
description: 'Id du couple courant (null si aucun / premier couple implicite côté client)',
})
couple_courant_id: string | null;
}
@@ -0,0 +1,13 @@
import { ApiProperty } from '@nestjs/swagger';
import { IsNotEmpty, IsUUID } from 'class-validator';
/** Corps PUT couple de garde courant — ticket #168 */
export class DefinirCoupleGardeCourantDto {
@ApiProperty({
format: 'uuid',
description: 'Id du placement (enfants_assistantes_maternelles.id) à sélectionner',
})
@IsUUID()
@IsNotEmpty()
couple_id: string;
}
@@ -13,7 +13,10 @@ describe('ParentsController', () => {
createParentDossierStaff: jest.fn(), createParentDossierStaff: jest.fn(),
addCoParentStaff: jest.fn(), addCoParentStaff: jest.fn(),
}; };
const parentsServiceMock = {}; const parentsServiceMock = {
listerCouplesGarde: jest.fn(),
definirCoupleGardeCourant: jest.fn(),
};
const userServiceMock = {}; const userServiceMock = {};
beforeEach(async () => { beforeEach(async () => {
@@ -39,6 +42,31 @@ describe('ParentsController', () => {
expect(controller).toBeDefined(); expect(controller).toBeDefined();
}); });
it('listerCouplesGarde délègue au service (#168)', async () => {
parentsServiceMock.listerCouplesGarde.mockResolvedValue({
couples: [],
couple_courant_id: null,
});
const res = await controller.listerCouplesGarde('parent-uuid');
expect(parentsServiceMock.listerCouplesGarde).toHaveBeenCalledWith('parent-uuid');
expect(res.couples).toEqual([]);
});
it('definirCoupleGardeCourant délègue au service (#168)', async () => {
parentsServiceMock.definirCoupleGardeCourant.mockResolvedValue({
couples: [{ id: 'pl-1', courant: true }],
couple_courant_id: 'pl-1',
});
const res = await controller.definirCoupleGardeCourant('parent-uuid', {
couple_id: 'pl-1',
});
expect(parentsServiceMock.definirCoupleGardeCourant).toHaveBeenCalledWith(
'parent-uuid',
'pl-1',
);
expect(res.couple_courant_id).toBe('pl-1');
});
it('createDossier delegates to authService.createParentDossierStaff with CGU accepted', async () => { it('createDossier delegates to authService.createParentDossierStaff with CGU accepted', async () => {
authServiceMock.createParentDossierStaff.mockResolvedValue({ authServiceMock.createParentDossierStaff.mockResolvedValue({
message: 'Dossier famille créé et validé. Un e-mail de création de mot de passe a été envoyé.', message: 'Dossier famille créé et validé. Un e-mail de création de mot de passe a été envoyé.',
@@ -8,6 +8,7 @@ import {
Param, Param,
Patch, Patch,
Post, Post,
Put,
UseGuards, UseGuards,
} from '@nestjs/common'; } from '@nestjs/common';
import { ParentsService } from './parents.service'; import { ParentsService } from './parents.service';
@@ -39,6 +40,8 @@ import { User } from 'src/common/decorators/user.decorator';
import { PendingFamilyDto } from './dto/pending-family.dto'; import { PendingFamilyDto } from './dto/pending-family.dto';
import { DossierFamilleCompletDto } from './dto/dossier-famille-complet.dto'; import { DossierFamilleCompletDto } from './dto/dossier-famille-complet.dto';
import { mapParentForApi, mapParentsForApi } from './parents.mapper'; import { mapParentForApi, mapParentsForApi } from './parents.mapper';
import { CouplesGardeResponseDto } from './dto/couples-garde.dto';
import { DefinirCoupleGardeCourantDto } from './dto/definir-couple-garde-courant.dto';
@ApiTags('Parents') @ApiTags('Parents')
@ApiBearerAuth('access-token') @ApiBearerAuth('access-token')
@@ -51,6 +54,39 @@ export class ParentsController {
private readonly authService: AuthService, private readonly authService: AuthService,
) {} ) {}
@Get('me/couples-garde')
@Roles(RoleType.PARENT)
@ApiOperation({
summary: 'Lister les couples de garde du parent connecté — ticket #168',
description:
'Retourne les placements actifs enfant↔AM rattachés au parent, ' +
'avec indication du couple courant (bandeau TdB quotidien).',
})
@ApiResponse({ status: 200, type: CouplesGardeResponseDto })
@ApiResponse({ status: 403, description: 'Réservé au rôle parent' })
@ApiResponse({ status: 404, description: 'Parent introuvable' })
listerCouplesGarde(@User('id') userId: string): Promise<CouplesGardeResponseDto> {
return this.parentsService.listerCouplesGarde(userId);
}
@Put('me/couples-garde/courant')
@Roles(RoleType.PARENT)
@ApiOperation({
summary: 'Définir le couple de garde courant — ticket #168',
description:
'Persiste la préférence de couple actif (enfant|nounou) pour contextualiser le TdB.',
})
@ApiBody({ type: DefinirCoupleGardeCourantDto })
@ApiResponse({ status: 200, type: CouplesGardeResponseDto })
@ApiResponse({ status: 400, description: 'Couple hors périmètre du parent' })
@ApiResponse({ status: 404, description: 'Parent ou couple introuvable' })
definirCoupleGardeCourant(
@User('id') userId: string,
@Body() dto: DefinirCoupleGardeCourantDto,
): Promise<CouplesGardeResponseDto> {
return this.parentsService.definirCoupleGardeCourant(userId, dto.couple_id);
}
@Roles(RoleType.SUPER_ADMIN, RoleType.ADMINISTRATEUR, RoleType.GESTIONNAIRE) @Roles(RoleType.SUPER_ADMIN, RoleType.ADMINISTRATEUR, RoleType.GESTIONNAIRE)
@Post('dossier') @Post('dossier')
@HttpCode(HttpStatus.CREATED) @HttpCode(HttpStatus.CREATED)
+9 -1
View File
@@ -5,6 +5,7 @@ import { JwtModule } from '@nestjs/jwt';
import { Parents } from 'src/entities/parents.entity'; import { Parents } from 'src/entities/parents.entity';
import { DossierFamille, DossierFamilleEnfant } from 'src/entities/dossier_famille.entity'; import { DossierFamille, DossierFamilleEnfant } from 'src/entities/dossier_famille.entity';
import { ParentsChildren } from 'src/entities/parents_children.entity'; import { ParentsChildren } from 'src/entities/parents_children.entity';
import { AmChildren } from 'src/entities/am_children.entity';
import { ParentsController } from './parents.controller'; import { ParentsController } from './parents.controller';
import { ParentsService } from './parents.service'; import { ParentsService } from './parents.service';
import { Users } from 'src/entities/users.entity'; import { Users } from 'src/entities/users.entity';
@@ -13,7 +14,14 @@ import { AuthModule } from '../auth/auth.module';
@Module({ @Module({
imports: [ imports: [
TypeOrmModule.forFeature([Parents, Users, DossierFamille, DossierFamilleEnfant, ParentsChildren]), TypeOrmModule.forFeature([
Parents,
Users,
DossierFamille,
DossierFamilleEnfant,
ParentsChildren,
AmChildren,
]),
forwardRef(() => UserModule), forwardRef(() => UserModule),
forwardRef(() => AuthModule), forwardRef(() => AuthModule),
JwtModule.registerAsync({ JwtModule.registerAsync({
@@ -1,12 +1,43 @@
import { BadRequestException, NotFoundException } from '@nestjs/common';
import { Test, TestingModule } from '@nestjs/testing'; import { Test, TestingModule } from '@nestjs/testing';
import { getRepositoryToken } from '@nestjs/typeorm';
import { ParentsService } from './parents.service'; import { ParentsService } from './parents.service';
import { Parents } from 'src/entities/parents.entity';
import { Users } from 'src/entities/users.entity';
import { DossierFamille } from 'src/entities/dossier_famille.entity';
import { ParentsChildren } from 'src/entities/parents_children.entity';
import { AmChildren } from 'src/entities/am_children.entity';
describe('ParentsService', () => { describe('ParentsService — couples de garde (#168)', () => {
let service: ParentsService; let service: ParentsService;
const parentsRepository = {
findOne: jest.fn(),
update: jest.fn(),
};
const parentsChildrenRepository = {
find: jest.fn(),
findOne: jest.fn(),
};
const amChildrenRepository = {
find: jest.fn(),
findOne: jest.fn(),
};
beforeEach(async () => { beforeEach(async () => {
jest.clearAllMocks();
const module: TestingModule = await Test.createTestingModule({ const module: TestingModule = await Test.createTestingModule({
providers: [ParentsService], providers: [
ParentsService,
{ provide: getRepositoryToken(Parents), useValue: parentsRepository },
{ provide: getRepositoryToken(Users), useValue: {} },
{ provide: getRepositoryToken(DossierFamille), useValue: {} },
{
provide: getRepositoryToken(ParentsChildren),
useValue: parentsChildrenRepository,
},
{ provide: getRepositoryToken(AmChildren), useValue: amChildrenRepository },
],
}).compile(); }).compile();
service = module.get<ParentsService>(ParentsService); service = module.get<ParentsService>(ParentsService);
@@ -15,4 +46,107 @@ describe('ParentsService', () => {
it('should be defined', () => { it('should be defined', () => {
expect(service).toBeDefined(); expect(service).toBeDefined();
}); });
describe('listerCouplesGarde', () => {
it('retourne une liste vide si le parent na pas denfant', async () => {
parentsRepository.findOne.mockResolvedValue({
user_id: 'p1',
id_placement_garde_courant: null,
});
parentsChildrenRepository.find.mockResolvedValue([]);
const res = await service.listerCouplesGarde('p1');
expect(res).toEqual({ couples: [], couple_courant_id: null });
expect(amChildrenRepository.find).not.toHaveBeenCalled();
});
it('mappe les placements actifs en couples et marque le courant', async () => {
parentsRepository.findOne.mockResolvedValue({
user_id: 'p1',
id_placement_garde_courant: 'pl-2',
});
parentsChildrenRepository.find.mockResolvedValue([
{ enfantId: 'e1' },
{ enfantId: 'e2' },
]);
amChildrenRepository.find.mockResolvedValue([
{
id: 'pl-1',
amId: 'am-1',
child: { id: 'e1', first_name: 'Léo', last_name: 'M', photo_url: null },
am: { user: { prenom: 'Marie', nom: 'N', photo_url: '/a.jpg' } },
},
{
id: 'pl-2',
amId: 'am-2',
child: { id: 'e2', first_name: 'Léa', last_name: 'M', photo_url: null },
am: { user: { prenom: 'Sophie', nom: 'P', photo_url: null } },
},
]);
const res = await service.listerCouplesGarde('p1');
expect(res.couples).toHaveLength(2);
expect(res.couple_courant_id).toBe('pl-2');
expect(res.couples[1].courant).toBe(true);
expect(res.couples[0].am.prenom).toBe('Marie');
expect(res.couples[0].enfant.prenom).toBe('Léo');
});
it('404 si parent inconnu', async () => {
parentsRepository.findOne.mockResolvedValue(null);
await expect(service.listerCouplesGarde('x')).rejects.toBeInstanceOf(
NotFoundException,
);
});
});
describe('definirCoupleGardeCourant', () => {
it('persiste le couple si lenfant est rattaché au parent', async () => {
parentsRepository.findOne.mockResolvedValue({
user_id: 'p1',
id_placement_garde_courant: null,
});
amChildrenRepository.findOne.mockResolvedValue({
id: 'pl-1',
enfantId: 'e1',
date_fin: null,
});
parentsChildrenRepository.findOne.mockResolvedValue({
parentId: 'p1',
enfantId: 'e1',
});
parentsRepository.update.mockResolvedValue({ affected: 1 });
// second call via listerCouplesGarde
parentsChildrenRepository.find.mockResolvedValue([{ enfantId: 'e1' }]);
amChildrenRepository.find.mockResolvedValue([
{
id: 'pl-1',
amId: 'am-1',
child: { id: 'e1', first_name: 'Léo', last_name: null, photo_url: null },
am: { user: { prenom: 'Marie', nom: null, photo_url: null } },
},
]);
const res = await service.definirCoupleGardeCourant('p1', 'pl-1');
expect(parentsRepository.update).toHaveBeenCalledWith(
{ user_id: 'p1' },
{ id_placement_garde_courant: 'pl-1' },
);
expect(res.couple_courant_id).toBe('pl-1');
expect(res.couples[0].courant).toBe(true);
});
it('400 si le couple nappartient pas au parent', async () => {
parentsRepository.findOne.mockResolvedValue({ user_id: 'p1' });
amChildrenRepository.findOne.mockResolvedValue({
id: 'pl-1',
enfantId: 'e99',
});
parentsChildrenRepository.findOne.mockResolvedValue(null);
await expect(
service.definirCoupleGardeCourant('p1', 'pl-1'),
).rejects.toBeInstanceOf(BadRequestException);
});
});
}); });
+109 -1
View File
@@ -5,7 +5,7 @@ import {
NotFoundException, NotFoundException,
} from '@nestjs/common'; } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm'; import { InjectRepository } from '@nestjs/typeorm';
import { In, Repository } from 'typeorm'; import { In, IsNull, Repository } from 'typeorm';
import { Parents } from 'src/entities/parents.entity'; import { Parents } from 'src/entities/parents.entity';
import { DossierFamille } from 'src/entities/dossier_famille.entity'; import { DossierFamille } from 'src/entities/dossier_famille.entity';
import { RoleType, Users } from 'src/entities/users.entity'; import { RoleType, Users } from 'src/entities/users.entity';
@@ -20,6 +20,8 @@ import {
import { ParentsChildren } from 'src/entities/parents_children.entity'; import { ParentsChildren } from 'src/entities/parents_children.entity';
import { Children } from 'src/entities/children.entity'; import { Children } from 'src/entities/children.entity';
import { UpdateParentFicheAdminDto } from './dto/update-parent-fiche-admin.dto'; import { UpdateParentFicheAdminDto } from './dto/update-parent-fiche-admin.dto';
import { AmChildren } from 'src/entities/am_children.entity';
import { CouplesGardeResponseDto } from './dto/couples-garde.dto';
@Injectable() @Injectable()
export class ParentsService { export class ParentsService {
@@ -32,6 +34,8 @@ export class ParentsService {
private readonly dossierFamilleRepository: Repository<DossierFamille>, private readonly dossierFamilleRepository: Repository<DossierFamille>,
@InjectRepository(ParentsChildren) @InjectRepository(ParentsChildren)
private readonly parentsChildrenRepository: Repository<ParentsChildren>, private readonly parentsChildrenRepository: Repository<ParentsChildren>,
@InjectRepository(AmChildren)
private readonly amChildrenRepository: Repository<AmChildren>,
) {} ) {}
// Création dun parent // Création dun parent
@@ -505,4 +509,108 @@ export class ParentsService {
} }
return raw.map((r: { id: string }) => r.id); return raw.map((r: { id: string }) => r.id);
} }
/**
* Liste les couples de garde (enfant ↔ AM) du parent connecté — ticket #168.
* Un couple = un placement actif dans enfants_assistantes_maternelles pour un enfant du parent.
*/
async listerCouplesGarde(parentUserId: string): Promise<CouplesGardeResponseDto> {
const parent = await this.parentsRepository.findOne({
where: { user_id: parentUserId },
});
if (!parent) {
throw new NotFoundException('Parent introuvable');
}
const liensEnfants = await this.parentsChildrenRepository.find({
where: { parentId: parentUserId },
select: ['enfantId'],
});
const enfantIds = liensEnfants.map((l) => l.enfantId);
if (enfantIds.length === 0) {
return { couples: [], couple_courant_id: null };
}
const placements = await this.amChildrenRepository.find({
where: { enfantId: In(enfantIds), date_fin: IsNull() },
relations: ['child', 'am', 'am.user'],
order: { date_debut: 'ASC' },
});
let idCourant = parent.id_placement_garde_courant ?? null;
const idsValides = new Set(placements.map((p) => p.id));
if (idCourant && !idsValides.has(idCourant)) {
idCourant = null;
await this.parentsRepository.update(
{ user_id: parentUserId },
{ id_placement_garde_courant: () => 'NULL' },
);
}
if (!idCourant && placements.length === 1) {
idCourant = placements[0].id;
}
const couples = placements.map((p) => {
const amUser = p.am?.user;
return {
id: p.id,
enfant: {
id: p.child.id,
prenom: p.child.first_name ?? null,
nom: p.child.last_name ?? null,
photo_url: p.child.photo_url ?? null,
},
am: {
id: p.amId,
prenom: amUser?.prenom ?? null,
nom: amUser?.nom ?? null,
photo_url: amUser?.photo_url ?? null,
},
courant: idCourant != null && p.id === idCourant,
};
});
return {
couples,
couple_courant_id: idCourant,
};
}
/**
* Persiste le couple de garde actif pour le parent — ticket #168.
*/
async definirCoupleGardeCourant(
parentUserId: string,
coupleId: string,
): Promise<CouplesGardeResponseDto> {
const parent = await this.parentsRepository.findOne({
where: { user_id: parentUserId },
});
if (!parent) {
throw new NotFoundException('Parent introuvable');
}
const placement = await this.amChildrenRepository.findOne({
where: { id: coupleId, date_fin: IsNull() },
});
if (!placement) {
throw new NotFoundException('Couple de garde introuvable ou inactif');
}
const lien = await this.parentsChildrenRepository.findOne({
where: { parentId: parentUserId, enfantId: placement.enfantId },
});
if (!lien) {
throw new BadRequestException(
'Ce couple ne concerne pas un enfant rattaché à ce parent',
);
}
await this.parentsRepository.update(
{ user_id: parentUserId },
{ id_placement_garde_courant: coupleId },
);
return this.listerCouplesGarde(parentUserId);
}
} }
+14 -1
View File
@@ -154,7 +154,10 @@ CREATE INDEX idx_assistantes_maternelles_numero_dossier
CREATE TABLE parents ( CREATE TABLE parents (
id_utilisateur UUID PRIMARY KEY REFERENCES utilisateurs(id) ON DELETE CASCADE, id_utilisateur UUID PRIMARY KEY REFERENCES utilisateurs(id) ON DELETE CASCADE,
id_co_parent UUID REFERENCES utilisateurs(id), id_co_parent UUID REFERENCES utilisateurs(id),
numero_dossier VARCHAR(20) numero_dossier VARCHAR(20),
-- Préférence couple de garde actif (TdB quotidien) — ticket #168
-- FK ajoutée après création de enfants_assistantes_maternelles (voir ALTER plus bas)
id_placement_garde_courant UUID
); );
CREATE INDEX idx_parents_numero_dossier CREATE INDEX idx_parents_numero_dossier
@@ -206,6 +209,16 @@ CREATE UNIQUE INDEX uq_enfant_garde_active
ON enfants_assistantes_maternelles (id_enfant) ON enfants_assistantes_maternelles (id_enfant)
WHERE date_fin IS NULL; WHERE date_fin IS NULL;
-- FK couple courant parent → placement (#168) — après table enfants_assistantes_maternelles
ALTER TABLE parents
ADD CONSTRAINT fk_parents_placement_garde_courant
FOREIGN KEY (id_placement_garde_courant)
REFERENCES enfants_assistantes_maternelles(id) ON DELETE SET NULL;
CREATE INDEX idx_parents_placement_garde_courant
ON parents(id_placement_garde_courant)
WHERE id_placement_garde_courant IS NOT NULL;
-- ========================================================== -- ==========================================================
-- Table : dossier_famille (inscription parent — ticket #119) -- Table : dossier_famille (inscription parent — ticket #119)
-- ========================================================== -- ==========================================================
@@ -0,0 +1,10 @@
-- Ticket #168 — Couple de garde courant (préférence parent)
-- Idempotent : safe à rejouer.
ALTER TABLE parents
ADD COLUMN IF NOT EXISTS id_placement_garde_courant UUID
REFERENCES enfants_assistantes_maternelles(id) ON DELETE SET NULL;
CREATE INDEX IF NOT EXISTS idx_parents_placement_garde_courant
ON parents(id_placement_garde_courant)
WHERE id_placement_garde_courant IS NOT NULL;
+61 -70
View File
@@ -1,94 +1,85 @@
# 📚 Index de la Documentation - PtitsPas App # Index de la documentation P'titsPas
Bienvenue dans la documentation complète de l'application PtitsPas. Index de navigation du dépôt. Dernière révision : **septembre 2026** (CDC V1.4 + SRS users #117).
Ce fichier sert d'index pour naviguer dans toute la documentation du projet. ## Produit & versions
## 📖 Table des matières | Doc | Contenu |
|-----|---------|
| [01 — Cahier des charges V1.4](./01_CAHIER-DES-CHARGES.md) | CDC **complet** (cible) ; gestion utilisateurs alignée `v0.1.0` |
| [12 — SRS gestion utilisateurs](./12_SRS-GESTION-UTILISATEURS.md) | Spécification **technique** du domaine users / dossiers |
| [05 — Versions & milestones](./05_VERSIONS-ET-MILESTONES.md) | Semver Gitea + bilans |
| [29 — Bilan version 0.1.0](./29_BILAN-VERSION-0.1.0.md) | Tickets livrés 0.1.0 |
| [30 — Découpage tickets quotidien](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md) | Brouillon / backlog tickets parent/AM |
| [31 — Mini-spec quotidien parent/AM](./31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md) | Besoin figé atelier sept. 2026 |
| [04 — Roadmap générale](./04_ROADMAP-GENERALE.md) | Vision phases long terme |
| [28 — Évolution famille / responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) | Limites modèle foyer / contournements |
### 📋 Cahier des Charges ## Architecture & infra
- [**01 - Cahier des Charges**](./01_CAHIER-DES-CHARGES.md) - Cahier des charges complet du projet P'titsPas (V1.3 - 24/11/2025)
### Architecture & Infrastructure | Doc | Contenu |
- [**02 - Architecture**](./02_ARCHITECTURE.md) - Vue d'ensemble de l'architecture mono-repo et multi-conteneurs |-----|---------|
- [**03 - Déploiement**](./03_DEPLOYMENT.md) - Guide complet de déploiement et configuration CI/CD | [02 — Architecture](./02_ARCHITECTURE.md) | Mono-repo, conteneurs |
| [03 — Déploiement](./03_DEPLOYMENT.md) | Deploy / CI-CD |
| [10 — Database](./10_DATABASE.md) | Schéma BDD |
| [11 — API](./11_API.md) | Endpoints REST |
| [21 — Configuration système](./21_CONFIGURATION-SYSTEME.md) | Config on-premise |
| [99 — Règles de codage](./99_REGLES-CODAGE.md) | Conventions |
### Planification ## Workflows & métier
- [**04 - Roadmap Générale**](./04_ROADMAP-GENERALE.md) - Roadmap complète du projet (Phases 1 à 5+)
### Développement | Doc | Contenu |
- [**10 - Database Schema**](./10_DATABASE.md) - Schéma de la base de données et modèles |-----|---------|
- [**11 - API Documentation**](./11_API.md) - Documentation complète des endpoints REST | [20 — Workflow création de compte](./20_WORKFLOW-CREATION-COMPTE.md) | Inscription / validation (détail historique) |
- [**14 - Note backend config setup**](./14_NOTE-BACKEND-CONFIG-SETUP.md) - Setup configuration | [juridique/](./juridique/README.md) | CGU / CGC / privacy + [22 technique](./juridique/22_DOCUMENTS-LEGAUX.md) |
- [**92 - Note backend gestionnaires**](./92_NOTE-BACKEND-GESTIONNAIRES.md) - Gestionnaires
- [**99 - Règles de codage**](./99_REGLES-CODAGE.md) - Conventions de code
### Workflows Fonctionnels ## Charte & maquettes
- [**20 - Workflow Création de Compte**](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow complet de création et validation des comptes utilisateurs
- [**21 - Configuration Système**](./21_CONFIGURATION-SYSTEME.md) - Configuration on-premise dynamique
- [**22 - Documents Légaux**](./juridique/22_DOCUMENTS-LEGAUX.md) - Gestion CGU/Privacy avec versioning
### Juridique (sources & technique) | Doc | Contenu |
- [**Dossier juridique**](./juridique/README.md) - Index : CGU/CGC en Markdown, |-----|---------|
export PDF, lien vers la doc technique n°22 | [CHARTE_GRAPHIQUE.md](./CHARTE_GRAPHIQUE.md) | Charte UI |
| [maquettes/](./maquettes/README.md) | Maquettes TdB quotidien (réf. v4 + historique) |
### Projet & suivi (Gitea / tickets) ## Projet & outillage
- [**23 - Liste des Tickets**](./23_LISTE-TICKETS.md) - 61 tickets Phase 1 détaillés
- [**24 - Décisions Projet**](./24_DECISIONS-PROJET.md) - Décisions architecturales et fonctionnelles
- [**25 - Backlog Phase 2**](./25_PHASE-2-BACKLOG.md) - Fonctionnalités techniques reportées
- [**28 - Évolution famille et responsables**](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) - Modèle dossier/famille, recompositions, v1.0.0 vs post-1.0.0
- [**26 - API Gitea**](./26_GITEA-API.md) - Procédure d'utilisation de l'API Gitea (issues, PR, branches, labels)
- [**27 - Briefing frontend**](./27_BRIEFING-FRONTEND.md) - Accès Git, priorités, scripts Gitea (token)
### Archive & convention de nommage | Doc | Contenu |
- [**Dossier archive**](./archive/README.md) - Fichiers **sans** `NN_` déplacés |-----|---------|
(temporaires, obsolètes) ; règles de rangement et suppression | [23 — Suivi tickets](./23_SUIVI-TICKETS.md) | Pointeur Gitea |
- Pointeur : [PROCEDURE-API-GITEA.md](./PROCEDURE-API-GITEA.md) → voir **26** | [24 — Décisions projet](./24_DECISIONS-PROJET.md) | ADR / décisions |
| [26 — API Gitea](./26_GITEA-API.md) | Issues, PR, milestones |
| [27 — Briefing frontend](./27_BRIEFING-FRONTEND.md) | Accès Git, priorités |
### Exceptions de nommage (racine `docs/`) ## Audit
Fichiers **sans préfixe numérique** encore à la racine par **héritage** ou
références outils (`.cursorrules`, etc.) — **à renommer** en `NN_` quand
possible :
- `CHARTE_GRAPHIQUE.md`
- [`EVOLUTIONS_CDC.md`](./EVOLUTIONS_CDC.md) — écarts CDC / app ; voir aussi [**28 - Évolution famille**](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)
- `SuperNounou_Cahier_Des_Charges_Complet_V1.1.md`
- `SuperNounou_SSS-001.md`
### Administration (À créer) | Doc | Contenu |
- [**30 - Guide d'administration**](./30_ADMIN.md) - Gestion des utilisateurs, accès PgAdmin, logs |-----|---------|
- [**31 - Troubleshooting**](./31_TROUBLESHOOTING.md) - Résolution des problèmes courants | [90 — Audit YNOV](./90_AUDIT.md) | Analyse code étudiant |
### Frontend (À créer) ## Archive
- [**40 - Frontend Flutter**](./40_FRONTEND.md) - Structure de l'application mobile/web
### Audit & Analyse | Emplacement | Usage |
- [**90 - Audit du projet YNOV**](./90_AUDIT.md) - Analyse complète du code étudiant et fonctionnalités |-------------|--------|
| [archive/](./archive/README.md) | Obsolete / temporaires |
| [archive/obsolete/](./archive/obsolete/) | CDC V1.3, EVOLUTIONS_CDC, SuperNounou, listes figées |
## 🚀 Quick Start ## Données de test
| Doc | Contenu |
|-----|---------|
| [test-data/](./test-data/README.md) | Jeux utilisateurs test |
## Quick start
```bash ```bash
# Cloner le projet git clone … ptitspas-app
git clone ssh://gitea-jmartin/jmartin/app.git ptitspas-app
# Lancer l'environnement de développement
cd ptitspas-app cd ptitspas-app
docker compose up -d docker compose up -d
# Front https://app.ptits-pas.fr — API /api — PgAdmin /pgadmin
# Accéder aux services
Frontend: https://app.ptits-pas.fr
API: https://app.ptits-pas.fr/api
PgAdmin: https://app.ptits-pas.fr/pgadmin
``` ```
## 🔗 Liens utiles ## Liens
- **Gitea** : https://git.ptits-pas.fr - Gitea : https://git.ptits-pas.fr/jmartin/petitspas
- **Production** : https://app.ptits-pas.fr - Prod : https://app.ptits-pas.fr
- **Mail** : https://mail.ptits-pas.fr
## 📝 Maintenance
Cette documentation est maintenue par Julien Martin (julien.martin@ptits-pas.fr).
Dernière mise à jour : Juin 2026
Mainteneur : Julien Martin (julien.martin@ptits-pas.fr).
+155 -70
View File
@@ -1,14 +1,19 @@
--- ---
title: "P'titsPas - Cahier des Charges Fonctionnel" title: "P'titsPas - Cahier des Charges Fonctionnel"
author: "Julien MARTIN" author: "Julien MARTIN"
date: "Novembre 2025" date: "Septembre 2026"
version: "v1.3" version: "v1.4"
--- ---
# P'titsPas Cahier des Charges Fonctionnel # P'titsPas Cahier des Charges Fonctionnel
> **Objet :** Définir le périmètre fonctionnel, les rôles utilisateurs, les processus métiers et les exigences techniques de la plateforme P'titsPas, destinée à accompagner les collectivités locales dans la gestion de la garde denfants. > **Objet :** Définir le périmètre fonctionnel, les rôles utilisateurs, les processus métiers et les exigences techniques de la plateforme P'titsPas, destinée à accompagner les collectivités locales dans la gestion de la garde denfants.
> **V1.4 (sept. 2026)** — Mise à jour de la **gestion des utilisateurs / dossiers / validation** pour coller au livré produit **`v0.1.0`**. Le reste du CDC (contrats, messagerie, agenda, paie, recherche AM, etc.) est **conservé** comme cible fonctionnelle.
> Détail technique du domaine utilisateurs : [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md).
> Bilan tickets `v0.1.0` : [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md).
> Archive V1.3 : [archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md](./archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md).
--- ---
## Historique des versions ## Historique des versions
@@ -19,6 +24,7 @@ version: "v1.3"
| 1.1 | 24/04/2025 | Julien MARTIN | Ajouts : gestion multi-enfants, fin de contrat, tableau de bord étendu | | 1.1 | 24/04/2025 | Julien MARTIN | Ajouts : gestion multi-enfants, fin de contrat, tableau de bord étendu |
| 1.2 | 26/05/2025 | Julien MARTIN | Remplacement de "SuperNounou" par "P'titsPas" | | 1.2 | 26/05/2025 | Julien MARTIN | Remplacement de "SuperNounou" par "P'titsPas" |
| 1.3 | 24/11/2025 | Julien MARTIN | Correction : retrait photo de profil parent (section 3.1.1) | | 1.3 | 24/11/2025 | Julien MARTIN | Correction : retrait photo de profil parent (section 3.1.1) |
| **1.4** | **15/09/2026** | Julien MARTIN | **Gestion utilisateurs** alignée `v0.1.0` (dossiers, validation/refus/reprise, fiches staff, suppressions, retrait naissance multiple & SMS) ; reste du CDC inchangé en cible |
--- ---
@@ -42,6 +48,8 @@ version: "v1.3"
### 3.4 Création dun administrateur ### 3.4 Création dun administrateur
### 3.5 Fiche enfant ### 3.5 Fiche enfant
### 3.6 Authentification et sécurité ### 3.6 Authentification et sécurité
### 3.7 Numéro de dossier, validation, refus et reprise
### 3.8 Suppressions (vue métier)
## 4. Tableaux de bord ## 4. Tableaux de bord
### 4.1 Vue densemble ### 4.1 Vue densemble
@@ -60,15 +68,15 @@ version: "v1.3"
#### 4.3.5 Heures supplémentaires #### 4.3.5 Heures supplémentaires
#### 4.3.6 Messagerie #### 4.3.6 Messagerie
### 4.4 Tableau de bord des gestionnaires ### 4.4 Tableau de bord des gestionnaires
#### 4.4.1 Comptes à valider #### 4.4.1 Dossiers à valider
#### 4.4.2 Liste des utilisateurs #### 4.4.2 Gestion des utilisateurs (partagée)
#### 4.4.3 Contrats #### 4.4.3 Contrats
#### 4.4.4 Messagerie #### 4.4.4 Messagerie
#### 4.4.5 Événements RPE #### 4.4.5 Événements RPE
#### 4.4.6 Alertes #### 4.4.6 Alertes
### 4.5 Tableau de bord des administrateurs ### 4.5 Tableau de bord des administrateurs
#### 4.5.1 Menu Profil #### 4.5.1 Menu Profil
#### 4.5.2 Gestion des utilisateurs #### 4.5.2 Gestion des utilisateurs (partagée admin + gestionnaire)
#### 4.5.3 Gestion des enfants #### 4.5.3 Gestion des enfants
#### 4.5.4 Paramètres de la plateforme #### 4.5.4 Paramètres de la plateforme
#### 4.5.5 Statistiques et supervision #### 4.5.5 Statistiques et supervision
@@ -193,18 +201,23 @@ Les assistantes maternelles peuvent :
Les gestionnaires (responsables de relais petite enfance) disposent dun tableau de bord de supervision. Ils peuvent : Les gestionnaires (responsables de relais petite enfance) disposent dun tableau de bord de supervision. Ils peuvent :
- Valider ou rejeter les demandes de création de compte - Valider ou refuser les **dossiers** (inscriptions parent / AM) et accompagner les reprises
- Suivre les mises en relation et les contrats - rer les usagers (fiches parent / AM / enfant, rattachements, dossiers) — socle partagé avec ladmin
- Organiser des événements ou des rendez-vous - Suivre les mises en relation et les contrats (cible CDC)
- Gérer les conflits ou les fins de contrat - Organiser des événements ou des rendez-vous (cible CDC)
- Gérer les conflits ou les fins de contrat (cible CDC)
- Lancer des sondages ou modérer un blog RPE (si activé) - Lancer des sondages ou modérer un blog RPE (si activé)
- Voir les historiques et statistiques liés à leur périmètre - Voir les historiques et statistiques liés à leur périmètre
Ils **ne créent pas** les comptes gestionnaire / administrateur (réservé à ladmin).
### 2.1.4 Administrateurs ### 2.1.4 Administrateurs
Les administrateurs sont les représentants techniques et institutionnels de la collectivité (DSI ou agents désignés). Ils peuvent : Les administrateurs sont les représentants techniques et institutionnels de la collectivité (DSI ou agents désignés). Ils peuvent :
- Créer ou supprimer des comptes (gestionnaires, parents, assistantes maternelles) - Tout ce que peut faire un gestionnaire sur les usagers / dossiers
- Créer ou supprimer des comptes **staff** (gestionnaires, administrateurs) selon garde-fous
- Créer ou supprimer des comptes usagers (parents, AM, enfants) selon droits
- Personnaliser linterface (logo, couleurs, nom de la ville) - Personnaliser linterface (logo, couleurs, nom de la ville)
- Activer ou désactiver des modules complémentaires - Activer ou désactiver des modules complémentaires
- Consulter les statistiques dusage - Consulter les statistiques dusage
@@ -245,12 +258,15 @@ Le parcours de création dun compte parent seffectue en plusieurs étapes
**Note** : Le parent 2 ne définit **pas** de mot de passe lors de l'inscription. Il recevra un email avec un lien pour créer son mot de passe après validation du gestionnaire. Cette approche est particulièrement adaptée aux situations de parents séparés ou divorcés où la communication peut être difficile. **Note** : Le parent 2 ne définit **pas** de mot de passe lors de l'inscription. Il recevra un email avec un lien pour créer son mot de passe après validation du gestionnaire. Cette approche est particulièrement adaptée aux situations de parents séparés ou divorcés où la communication peut être difficile.
### 3.1.3 Informations sur l'enfant ### 3.1.3 Informations sur l'enfant
- Un ou **plusieurs** enfants peuvent être ajoutés
- Prénom (facultatif si enfant à naître) - Prénom (facultatif si enfant à naître)
- Nom (hérité des parents) - Nom (hérité des parents)
- Genre (H / F) - obligatoire - Genre (H / F / Autre) obligatoire
- Date de naissance ou **date prévisionnelle de naissance** (si l'enfant n'est pas encore né, un switch modifie le label) - Date de naissance ou **date prévisionnelle de naissance** (si l'enfant n'est pas encore né, un switch modifie le label)
- Photo obligatoire si l'enfant est né - Photo (selon règles dinscription) et **consentement photo**
- Rattachement automatique aux deux parents - Rattachement automatique au parent 1 et au parent 2 sil est renseigné
**Note V1.4** : il nexiste **pas** de champ « naissance multiple / jumeaux » (retiré du produit).
### 3.1.4 Présentation du dossier ### 3.1.4 Présentation du dossier
- Zone de texte libre permettant aux parents de décrire leur situation - Zone de texte libre permettant aux parents de décrire leur situation
@@ -265,10 +281,12 @@ Le parcours de création dun compte parent seffectue en plusieurs étapes
### 3.1.6 Récapitulatif et validation ### 3.1.6 Récapitulatif et validation
- Résumé des données saisies - Résumé des données saisies
- Vérification, puis envoi de la demande - Vérification, puis envoi de la demande
- Attribution dun **numéro de dossier** (format type AAAA-NNNNNN)
- Les comptes parent sont soumis à validation par un gestionnaire avant activation - Les comptes parent sont soumis à validation par un gestionnaire avant activation
- Une fois validé, chaque parent (Parent 1 et Parent 2 si renseigné) reçoit un e-mail ou un SMS contenant un lien pour créer son mot de passe - Une fois validé, chaque parent (Parent 1 et Parent 2 si renseigné) reçoit un **e-mail** contenant un lien pour créer son mot de passe
- Le lien est valable pendant 7 jours - Le lien est valable pendant une durée limitée (jeton à usage unique)
- Une fois le mot de passe créé, le parent peut se connecter à son espace - Une fois le mot de passe créé, le parent peut se connecter à son espace
- En cas de **refus**, le dossier nest pas supprimé : lusager peut **reprendre** sa demande (lien e-mail ou numéro de dossier) — voir §3.7
## 3.2 Création de compte assistante maternelle ## 3.2 Création de compte assistante maternelle
@@ -298,7 +316,7 @@ Ce parcours est divisé en deux panneaux.
- Champ libre : message à destination du gestionnaire - Champ libre : message à destination du gestionnaire
- Permet de justifier une demande ou dajouter des précisions - Permet de justifier une demande ou dajouter des précisions
### 3.1.4 Acceptation des CGU ### 3.2.4 Acceptation des CGU
- Les utilisateurs doivent cocher la case - Les utilisateurs doivent cocher la case
« Jai lu et jaccepte les Conditions Générales dUtilisation et la Politique de confidentialité ». « Jai lu et jaccepte les Conditions Générales dUtilisation et la Politique de confidentialité ».
- Un lien direct ouvre la version PDF des CGU. - Un lien direct ouvre la version PDF des CGU.
@@ -307,23 +325,26 @@ Ce parcours est divisé en deux panneaux.
### 3.2.5 Récapitulatif et validation ### 3.2.5 Récapitulatif et validation
- Résumé des données saisies - Résumé des données saisies
- Vérification, puis envoi de la demande - Vérification, puis envoi de la demande
- Attribution dun **numéro de dossier**
- Validation par un gestionnaire requise avant activation - Validation par un gestionnaire requise avant activation
- Une fois validé, l'assistante maternelle reçoit un e-mail ou un SMS contenant un lien pour créer son mot de passe - Une fois validé, l'assistante maternelle reçoit un **e-mail** contenant un lien pour créer son mot de passe
- Le lien est valable pendant 7 jours - Le lien est valable pendant une durée limitée (jeton à usage unique)
- Une fois le mot de passe créé, l'assistante maternelle peut se connecter à son espace - Une fois le mot de passe créé, l'assistante maternelle peut se connecter à son espace
- En cas de **refus** : reprise possible — voir §3.7
## 3.3 Création dun gestionnaire ## 3.3 Création dun gestionnaire
- Réalisée par un administrateur - Réalisée par un **administrateur** (ou super administrateur) — un gestionnaire ne crée pas de comptes staff
- Champs obligatoires : nom, prénom, adresse e-mail, mot de passe - Champs : nom, prénom, e-mail, téléphone, mot de passe, **relais principal** (optionnel)
- Affectation à un ou plusieurs relais petite enfance - Le mot de passe peut être modifié à la première connexion si la politique lexige
- Le mot de passe doit être modifié lors de la première connexion - Formulaire unifié de création / édition (même présentation que pour les administrateurs)
## 3.4 Création dun administrateur ## 3.4 Création dun administrateur
- Seuls les administrateurs existants peuvent créer de nouveaux comptes administrateurs - Seuls les **administrateurs** (et super administrateur) peuvent créer de nouveaux comptes administrateurs
- Les droits sont équivalents (possibilité de restreindre par périmètre dans une version multi-mairies) - Champs : nom, prénom, e-mail, téléphone, mot de passe (pas de relais)
- Obligation de changer le mot de passe à la première connexion - Les droits sont équivalents entre administrateurs (le **super administrateur** est un compte dinstallation non supprimable)
- Obligation de changer le mot de passe à la première connexion si exigé
## 3.5 Fiche enfant ## 3.5 Fiche enfant
@@ -331,22 +352,68 @@ Chaque enfant est représenté par une fiche :
- Prénom (facultatif si enfant à naître) - Prénom (facultatif si enfant à naître)
- Nom - Nom
- Genre (H / F) - obligatoire - Genre (H / F / Autre) obligatoire
- Date de naissance ou date prévisionnelle - Date de naissance ou date prévisionnelle
- Photo (obligatoire si l'enfant est né ET si l'option *Photo obligatoire* est activée) - Photo et consentement photo selon configuration (consentement tracé)
- Consentement photo enregistré : valeur booléenne + horodatage liés à l'accord donné par le parent - Statut : à naître / actif / scolarisé (évolutions de libellés possibles ultérieurement)
- Statut : à naître / actif / scolarisé - Responsables (parents) rattachés — liens vers les fiches parent
- Indication possible : jumeaux, triplés, etc. - Assistante maternelle de rattachement (le cas échéant)
- Possibilité de rattacher un enfant à plusieurs parents (garde alternée)
**Note V1.4** : pas dindication « jumeaux / triplés » comme champ dédié.
Les fiches enfants sont :
- Accessibles depuis la fiche parent, la fiche AM, longlet **Enfants** du dashboard staff
- Créables par le staff pour un foyer existant
- Partagées entre les responsables rattachés
## 3.6 Authentification et sécurité ## 3.6 Authentification et sécurité
- Tous les comptes utilisent une combinaison adresse e-mail + mot de passe - Authentification par e-mail + mot de passe
- Les gestionnaires et administrateurs doivent modifier leur mot de passe à la première connexion - Comptes **en attente** ou **suspendus** : connexion refusée
- Des mécanismes de récupération sont disponibles en cas de perte - Les gestionnaires et administrateurs doivent modifier leur mot de passe à la première connexion (si exigé)
- **Création de mot de passe** post-validation : lien e-mail (jeton TTL, usage unique)
- **Mot de passe oublié** : parcours distinct (demande → e-mail → réinitialisation)
- Pas denvoi de lien de mot de passe par SMS (canal **e-mail** uniquement)
Un lien direct vers les **Mentions légales** et la **Politique de confidentialité** est accessible en permanence depuis le pied de page, y compris avant la connexion. Un lien direct vers les **Mentions légales** et la **Politique de confidentialité** est accessible en permanence depuis le pied de page, y compris avant la connexion.
## 3.7 Numéro de dossier, validation, refus et reprise
### Numéro de dossier
- Format type **AAAA-NNNNNN**
- Affiché dans les listes staff, les modales et les e-mails concernés
- Sert de clé métier pour validation, refus et reprise
### Validation
- Le staff (gestionnaire / administrateur) examine le dossier (wizard de revue)
- Action **Valider** : activation du circuit comptes + e-mails de création de mot de passe
### Refus
- Action **Refuser** : le dossier est refusé **sans suppression** des données
- Lusager est informé par e-mail et peut reprendre sa demande
### Reprise
- Via le **lien** reçu par e-mail, ou depuis l’écran de connexion avec le **numéro de dossier**
- Formulaire prérempli / correction des informations
- Nouvelle soumission → retour en file « à valider »
### Création et édition de dossiers par le staff
- En plus de linscription publique, le staff peut **créer** un dossier famille ou AM (wizard)
- Le staff peut **éditer** un dossier existant (y compris ajout dun 2ᵉ parent pour une famille mono-parent)
## 3.8 Suppressions (vue métier)
Sous réserve des droits (détail technique : [SRS gestion utilisateurs](./12_SRS-GESTION-UTILISATEURS.md)) :
| Cible | Principe |
|-------|----------|
| Parent, AM, enfant, dossier | Gestionnaire, administrateur, super admin — avec confirmation |
| Gestionnaire | Administrateur / super admin uniquement |
| Administrateur | Admin / super admin, hors soi-même, hors cible super admin ; garde-fou sur le dernier administrateur |
| Super administrateur | Non supprimable |
Un gestionnaire ne peut pas supprimer **son propre** compte.
# 4. Tableaux de bord # 4. Tableaux de bord
Chaque rôle utilisateur dispose dun tableau de bord personnalisé, adapté à ses fonctions dans la plateforme. Ces interfaces sont pensées pour être lisibles, fonctionnelles et évolutives. Chaque rôle utilisateur dispose dun tableau de bord personnalisé, adapté à ses fonctions dans la plateforme. Ces interfaces sont pensées pour être lisibles, fonctionnelles et évolutives.
@@ -357,8 +424,8 @@ Chaque rôle utilisateur dispose dun tableau de bord personnalisé, adapté
|------------------------|-------------------------------------------------------------------| |------------------------|-------------------------------------------------------------------|
| Parents | Recherche d'assistante maternelle, gestion des enfants, contrat, agenda | | Parents | Recherche d'assistante maternelle, gestion des enfants, contrat, agenda |
| Assistantes maternelles| Dossiers reçus, enfants accueillis, heures sup, agenda, messagerie| | Assistantes maternelles| Dossiers reçus, enfants accueillis, heures sup, agenda, messagerie|
| Gestionnaires | Validation de comptes, contrats, messagerie, événements RPE | | Gestionnaires | Dossiers à valider, gestion utilisateurs/enfants (partagée), contrats, messagerie, événements RPE |
| Administrateurs | Paramètres globaux, gestion des utilisateurs, statistiques | | Administrateurs | Paramètres globaux, même gestion utilisateurs (droits staff élargis), statistiques |
Les tableaux de bord intègrent : Les tableaux de bord intègrent :
- Une **barre de navigation supérieure** (liens de navigation rapide) - Une **barre de navigation supérieure** (liens de navigation rapide)
@@ -502,17 +569,24 @@ Lassistante maternelle accède à une interface dédiée à la gestion de ses
Le gestionnaire RPE dispose dune vision transversale sur les utilisateurs, les dossiers et les activités de la structure. Son rôle est d'accompagner, superviser, et arbitrer si nécessaire. Le gestionnaire RPE dispose dune vision transversale sur les utilisateurs, les dossiers et les activités de la structure. Son rôle est d'accompagner, superviser, et arbitrer si nécessaire.
### 4.4.1 Comptes à valider ### 4.4.1 Dossiers à valider
- File dattente des demandes de création de compte - File dattente des **dossiers** (famille / AM) en attente de validation
- Détails de chaque demande : parent, assistante maternelle - Affichage du **numéro de dossier** et des informations essentielles
- Actions possibles : Valider / Refuser / Demander des précisions - Ouverture en **revue** (wizard étapes) : Valider / Refuser
- Le refus nefface pas le dossier : lusager peut reprendre (voir §3.7)
- Longlet **Dossiers** du dashboard regroupe aussi une **liste unifiée** des dossiers (au-delà de la seule file « à valider »)
### 4.4.2 Liste des utilisateurs ### 4.4.2 Gestion des utilisateurs (partagée)
- Filtres par rôle, statut, date dinscription > **V1.4** — La gestion opérationnelle des usagers (parents, AM, enfants, dossiers) est **partagée** entre gestionnaire et administrateur via le même dashboard. Seule la gestion des **comptes staff** (création / suppression gestionnaire ou admin) est réservée à ladministrateur.
- Accès rapide aux informations et historiques
- Possibilité de contacter un utilisateur - Onglets : Parents, Assistantes maternelles, Enfants, Gestionnaires (selon droits), Administrateurs (admin)
- Accès aux **fiches** (identité, rattachements, capacité AM, etc.)
- Création de dossiers / enfants par le staff
- Filtres et recherche ; ouverture des fiches depuis les cartes / listes
Le détail des panneaux admin historiques est décrit en §4.5.2 (même socle fonctionnel).
### 4.4.3 Contrats ### 4.4.3 Contrats
@@ -566,47 +640,56 @@ Le menu profil de ladministrateur comprend uniquement :
Toutes les fonctionnalités de gestion sont accessibles via des onglets distincts dans le tableau de bord. Toutes les fonctionnalités de gestion sont accessibles via des onglets distincts dans le tableau de bord.
### 4.5.2 Gestion des utilisateurs ### 4.5.2 Gestion des utilisateurs (partagée admin + gestionnaire)
Ladministration des utilisateurs est organisée par panneaux distincts pour chaque type de profil. Ladministration des utilisateurs est organisée par panneaux / onglets. **Admin et gestionnaire** partagent les panneaux usagers ; ladmin dispose en plus des droits staff.
#### a. Gestion des gestionnaires #### a. Gestion des gestionnaires
- Liste des gestionnaires existants - Liste des gestionnaires existants
- Création (nom, prénom, e-mail, mot de passe) - Création / édition (nom, prénom, e-mail, téléphone, mot de passe, relais principal) — **administrateur uniquement** pour la création
- Attribution à un ou plusieurs RPE - Réinitialisation / nouveau mot de passe en édition
- Réinitialisation du mot de passe - Suppression du compte — **administrateur uniquement** (pas dauto-suppression)
- Suppression du compte
#### b. Gestion des parents #### b. Gestion des parents
- Liste complète des parents enregistrés - Liste des parents enregistrés
- Recherche par nom, statut, enfants associés - Ouverture de la **fiche parent** (identité, statut, enfants, lien co-parent)
- Modification des informations - Rattacher / détacher un enfant
- Suppression dun compte - Création de dossier famille (wizard staff)
- Consultation du statut des dossiers liés - Suppression dun compte / dossier selon droits (§3.8)
#### c. Gestion des assistantes maternelles #### c. Gestion des assistantes maternelles
- Liste des assistantes avec numéro dagrément - Liste des AM (agrément, capacité, etc.)
- Modification ou suppression dun compte - **Fiche AM** (identité, professionnel, enfants accueillis)
- Filtrage par zone géographique ou capacité - Respect de la **capacité max** pour les rattachements
- Création de dossier AM (wizard staff)
- Suppression selon droits
#### d. Gestion des administrateurs #### d. Gestion des administrateurs
- Création de nouveaux comptes administrateurs - Création de nouveaux comptes administrateurs**administrateur / super admin**
- Suivi des droits - Suivi des droits
- Obligation de modification du mot de passe à la première connexion - Obligation de modification du mot de passe à la première connexion si exigé
- Suppression avec garde-fous (pas soi-même, pas le super admin, dernier admin)
#### e. Onglet Dossiers
- Liste unifiée + dossiers à valider
- Revue / édition des dossiers (wizards)
### 4.5.3 Gestion des enfants ### 4.5.3 Gestion des enfants
Deux accès possibles à la gestion des enfants : Deux accès possibles à la gestion des enfants :
#### a. Par fiche parent #### a. Par fiche parent (ou fiche AM)
- Consultation et édition des enfants associés à chaque parent - Consultation et édition des enfants associés
- Rattacher / détacher depuis la fiche
#### b. Vue globale “Enfants” #### b. Vue globale “Enfants”
- Liste complète avec : - Liste complète avec :
- Nom, prénom, date de naissance ou prévisionnelle - Nom, prénom, date de naissance ou prévisionnelle
- Statut (à naître, actif, scolarisé) - Statut (à naître, actif, scolarisé)
- Parents associés - Parents associés (alerte si **sans responsable**)
- Contrat en cours (si applicable) - AM associée le cas échéant
- Contrat en cours (si applicable — module contrats)
- Création dun enfant rattaché à un **foyer existant**
- Possibilité de modifier ou supprimer une fiche enfant - Possibilité de modifier ou supprimer une fiche enfant
### 4.5.4 Paramètres de la plateforme ### 4.5.4 Paramètres de la plateforme
@@ -905,10 +988,10 @@ Certains outils de la plateforme sont accessibles à plusieurs profils et favori
- Le gestionnaire (à titre dinformation) - Le gestionnaire (à titre dinformation)
- Contient : - Contient :
- Identité - Identité
- Photo (obligatoire si né) - Photo (selon configuration / consentement)
- Statut (à naître / actif / scolarisé) - Statut (à naître / actif / scolarisé)
- Parents associés - Parents associés
- Mention sil sagit de jumeaux, triplés, etc. - AM associée le cas échéant
## 6.4 Contrats et avenants ## 6.4 Contrats et avenants
@@ -1185,11 +1268,11 @@ P'titsPas sinscrit dans une démarche de service public, avec des fondements
| **Gestionnaires** | Suivi global des situations, outils de médiation, organisation d’événements | | **Gestionnaires** | Suivi global des situations, outils de médiation, organisation d’événements |
| **Administrateurs** | Supervision complète, gouvernance multi-rôle, contrôle des données | | **Administrateurs** | Supervision complète, gouvernance multi-rôle, contrôle des données |
## 10.3 Périmètre fonctionnel de la V1 ## 10.3 Périmètre fonctionnel
Fonctionnalités incluses dès la première version : **Cible CDC (plateforme complète)** — fonctionnalités décrites dans ce document :
- Création de comptes - Création de comptes et gestion des utilisateurs / dossiers
- Recherche et sélection de nounous - Recherche et sélection dassistantes maternelles
- Suivi des dossiers - Suivi des dossiers
- Génération de contrat et avenants - Génération de contrat et avenants
- Messagerie - Messagerie
@@ -1198,6 +1281,8 @@ Fonctionnalités incluses dès la première version :
- Gestion des heures supplémentaires - Gestion des heures supplémentaires
- Suivi RGPD et administration - Suivi RGPD et administration
**Livré produit `v0.1.0`** (voir [bilan](./29_BILAN-VERSION-0.1.0.md)) : cœur **gestion des utilisateurs** — inscription, validation/refus/reprise, auth, dashboard staff (dossiers, fiches, rattachements, suppressions). Les autres modules du CDC restent la **feuille de route**.
## 10.4 Perspectives ## 10.4 Perspectives
La structure du produit permet une montée en charge progressive : La structure du produit permet une montée en charge progressive :
+15 -15
View File
@@ -44,22 +44,21 @@ Les **Phases 2, 3, 4+** sont des **ébauches indicatives** qui seront affinées
- ✅ Logging & Monitoring - ✅ Logging & Monitoring
- ✅ Tests & Documentation - ✅ Tests & Documentation
### Versions incrémentales ### Versions incrémentales (semver / Gitea)
| Version | Objectif | Tickets | Estimation | La table historique « ~21 tickets / 0.1.0 » est **obsolète**.
|---------|----------|---------|------------| État réel des milestones, bilans et tag : **[05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)**.
| **0.1.0** | MVP Fonctionnel | ~21 | ~45h |
| **0.2.0** | Sécurité & RGPD | ~10 | ~35h |
| **0.3.0** | Interfaces Complètes | ~17 | ~52h |
| **0.4.0** | Tests & Documentation | ~6 | ~24h |
| **0.5.0** | Monitoring & Optimisations | ~7 | ~17h |
| **1.0.0** | 🎉 **Release Phase 1** | **61** | **~173h** |
### Livrable | Version | Statut (sept. 2026) |
|---------|---------------------|
| **0.1.0** | **Terminée** — [bilan](./29_BILAN-VERSION-0.1.0.md) (48 tickets fermés) |
| **0.2.0+** | Ouvertes — voir Gitea + doc 05 |
Application installable avec création et validation de comptes utilisateurs. ### Livrable Phase 1 (visée)
**Référence** : [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) Application installable avec création et validation de comptes utilisateurs, puis enrichissements dashboard / dossiers (0.1.0 livré).
**Tickets** : Gitea — pointeur [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md).
--- ---
@@ -216,7 +215,7 @@ Suivi quotidien des enfants + Fonctionnalités complémentaires.
Application mature, optimisée et riche en fonctionnalités. Application mature, optimisée et riche en fonctionnalités.
**Référence** : [25_PHASE-2-BACKLOG.md](./25_PHASE-2-BACKLOG.md) (anciennes fonctionnalités techniques) **Référence** : [archive/obsolete/25_PHASE-2-BACKLOG.md](./archive/obsolete/25_PHASE-2-BACKLOG.md) (figé) + [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)
--- ---
@@ -317,9 +316,10 @@ Exemples :
- [00_INDEX.md](./00_INDEX.md) - Index général de la documentation - [00_INDEX.md](./00_INDEX.md) - Index général de la documentation
- [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) - Cahier des charges v1.3 - [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) - Cahier des charges v1.3
- [20_WORKFLOW-CREATION-COMPTE.md](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow création de comptes - [20_WORKFLOW-CREATION-COMPTE.md](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow création de comptes
- [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) - Liste des 61 tickets Phase 1 - [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md) / [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) — suivi Gitea + bilan 0.1.0
- [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md) - Décisions architecturales - [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md) - Décisions architecturales
- [25_PHASE-2-BACKLOG.md](./25_PHASE-2-BACKLOG.md) - Anciennes fonctionnalités techniques - [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md) — milestones Gitea
- [archive/obsolete/25_PHASE-2-BACKLOG.md](./archive/obsolete/25_PHASE-2-BACKLOG.md) — backlog Phase 2 figé
--- ---
+66
View File
@@ -0,0 +1,66 @@
# Versions & milestones — P'titsPas
**Source de vérité tickets** : Gitea [`jmartin/petitspas`](https://git.ptits-pas.fr/jmartin/petitspas)
**Bilans de version** : documents `29_BILAN-…` (et suivants)
Ce fichier remplace, pour le **semver / milestones**, les anciennes tables figées de la roadmap Phase 1.
---
## État des milestones
| Milestone | Rôle | Statut |
|-----------|------|--------|
| **0.1.0** | MVP opérable (auth, inscription, dashboard dossiers/fiches, suppressions, cleanups) | **Terminée** — [bilan](./29_BILAN-VERSION-0.1.0.md) |
| **0.2.0** | **Quotidien parent / AM** (TdB 3 colonnes, cartes, blog, messagerie) — [#165](https://git.ptits-pas.fr/jmartin/petitspas/issues/165)… | **Ouverte** — [mini-spec](./31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md) · [découpage](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md) |
| **0.3.0** | Contrat + planning | Fermée (vide) — à réouvrir au besoin |
| **0.4.0** | Carnet de liaison | Fermée (vide) — à réouvrir au besoin |
| **0.9.0** | Hors périmètre cleanup 0.1.0 | Fermée (vide) |
| **1.0.0** | Release majeure (critères PO) | Fermée (réserve) |
| **Backlog transverse** | Doc / CI / RGPD / monitoring | Fermée (vide) |
Liens Gitea : [milestones](https://git.ptits-pas.fr/jmartin/petitspas/milestones).
---
## Bilans
| Version | Document |
|---------|----------|
| 0.1.0 | [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) |
## Documents produit de référence (post-0.1.0)
| Doc | Rôle |
|-----|------|
| [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) | CDC **complet** V1.4 (users mis à jour ; reste = cible) |
| [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md) | SRS technique domaine utilisateurs |
| [31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md](./31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md) | Besoin quotidien parent/AM (0.2.0) |
| [30_DECOUPAGE-TICKETS-QUOTIDIEN.md](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md) | Mapping tickets #165#189 |
| Archive CDC V1.3 | [archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md](./archive/obsolete/01_CAHIER-DES-CHARGES-v1.3.md) |
---
## Relation avec la roadmap phases
La vision long terme (Phases 25 : mise en relation, contrats, carnet…) reste dans [04_ROADMAP-GENERALE.md](./04_ROADMAP-GENERALE.md).
Les **jalons livrables** se gèrent ici + dans Gitea.
Ancien backlog « Phase 2 » technique ([archive](./archive/obsolete/25_PHASE-2-BACKLOG.md)) : à croiser avec les milestones ci-dessus ; ne plus maintenir en double.
---
## Suivi des tickets
- **Création / état** : Gitea uniquement.
- **Mémoire dune version livrée** : bilan `29_…` (pas de re-copie exhaustive dans un fichier tickets).
- Ancienne liste figée Phase 1 : [archive/obsolete/23_LISTE-TICKETS.md](./archive/obsolete/23_LISTE-TICKETS.md).
- Pointeur court : [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md).
---
## Tag Git
| Tag | Condition |
|-----|-----------|
| `v0.1.0` | Milestone 0.1.0 fermée + bilan mergé sur `master` |
+250
View File
@@ -0,0 +1,250 @@
# SRS — Gestion des utilisateurs (domaine livré v0.1.0)
**Version** : 1.0
**Date** : 15/09/2026
**Ticket** : [#117](https://git.ptits-pas.fr/jmartin/petitspas/issues/117)
**Niveau** : **technique** (dev / QA)
**CDC associé** : [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) (V1.4 — **CDC complet** ; cette SRS ne couvre que le domaine utilisateurs)
> Périmètre SRS : comptes, auth liée, dossiers famille/AM, enfants, affiliations, dashboard staff, suppressions.
> Le CDC V1.4 conserve **lensemble** des chapitres cibles (contrats, messagerie, etc.) ; ils ne sont **pas** redécrits ici.
> Hors SRS technique : OpenAPI exhaustif, PRA/CI → voir [11_API](./11_API.md), [10_DATABASE](./10_DATABASE.md).
---
## 1. Glossaire
| Terme | Définition |
|-------|------------|
| **User / utilisateur** | Compte authentifiable (`utilisateurs`) avec `role` et `statut` |
| **Parent pivot** | Responsable principal du foyer à linscription / création staff |
| **Co-parent** | Second responsable optionnel (au plus un), lié au pivot |
| **Foyer** | Pivot + co-parent éventuel + enfants affiliés |
| **Dossier** | Unité métier identifiée par `numero_dossier` (format `AAAA-NNNNNN`) — famille ou AM |
| **Pending / en_attente** | Compte ou dossier en attente de validation staff |
| **Refus** | Rejet sans suppression ; ouvre la **reprise** |
| **Relais** | Structure RPE ; rattachement optionnel dun gestionnaire |
| **Staff** | `gestionnaire`, `administrateur`, `super_admin` |
---
## 2. Acteurs et rôles applicatifs
| `role` | Inscription publique | Dashboard staff | Créer staff | Suppressions métier usagers | Supprimer gestionnaire | Supprimer admin |
|--------|---------------------|-----------------|-------------|----------------------------|------------------------|-----------------|
| `parent` | oui | non | non | non | non | non |
| `assistante_maternelle` | oui | non | non | non | non | non |
| `gestionnaire` | non (créé staff) | oui | non | oui* | non | non |
| `administrateur` | non | oui | oui | oui* | oui | oui** |
| `super_admin` | non (install) | oui | oui | oui* | oui | oui** |
\* Sous réserve des garde-fous (pas soi-même pour sa fiche staff, etc.).
\*\* Pas soi-même ; pas de cible `super_admin` ; dernier admin : règles `canDeleteAdministrateur` (front `staff_deletion_rights.dart`).
Réf. front : `frontend/lib/utils/staff_deletion_rights.dart`
- `canCreateStaffAccounts` → admin / super_admin
- `canDeleteMetier` → gestionnaire / admin / super_admin
- `canDeleteGestionnaire` → admin / super_admin
---
## 3. Statuts
### 3.1 Utilisateur (`statut_utilisateur_type`)
| Statut | Signification |
|--------|----------------|
| `en_attente` | Inscrit, non validé ; **login refusé** |
| `actif` | Validé / utilisable |
| `suspendu` | Bloqué ; **login refusé** |
### 3.2 Enfant (`statut_enfant_type`)
Valeurs actuelles : `a_naitre`, `actif`, `scolarise` (évolution métier « gardé / sans garde » **hors** cette SRS — ticket dédié).
### 3.3 Validation dossier
Circuit staff : revue → **valider** ou **refuser**. Refus ≠ delete. Reprise → nouveau passage en attente.
---
## 4. Modèle de données (vue synthétique)
```mermaid
flowchart TB
user[utilisateurs]
parent[parents]
am[assistantes_maternelles]
enfant[enfants]
ep[enfants_parents]
df[dossier_famille]
user --> parent
user --> am
parent --> ep
enfant --> ep
parent --> df
```
| Concept | Tables / liens clés |
|---------|---------------------|
| Compte | `utilisateurs` (role, statut, email, numero_dossier, relais…) |
| Parent | `parents` (+ `id_co_parent` optionnel) |
| AM | `assistantes_maternelles` (agrément, capacité, NIR…) |
| Enfant | `enfants` |
| Affiliation parent | `enfants_parents` (NN) |
| Dossier famille | `dossier_famille` (+ enfants dossier) |
| Tokens MDP | tables / flux tokens création & reset (TTL, usage unique) |
Détail colonnes : [10_DATABASE.md](./10_DATABASE.md).
### Invariants
1. **Pas** de champ `est_multiple` / naissance multiple (#152).
2. Au plus **un** co-parent par fiche parent.
3. Affiliation création enfant : rattache **pivot + co-parent** sil existe (#158).
4. Détachement du **dernier** parent → enfant **sans responsable** possible (#157).
5. Rattachement AM plafonné par **capacité** (#148 / #149).
6. `super_admin` **non supprimable**.
---
## 5. Flux
### 5.1 Inscription → validation → mot de passe
```mermaid
sequenceDiagram
participant U as Usager
participant API as API
participant S as Staff
participant M as Mail
U->>API: register parent/AM
API-->>U: numero_dossier, statut en_attente
S->>API: review / valider
API->>M: mail lien create-password
U->>API: verify token + set password
API-->>U: compte actif, login OK
```
Variante **refus** : staff refuse → mail refus → usager **reprise** (token lien ou n° dossier) → resoumission → à valider.
### 5.2 Mot de passe oublié
Flux distinct de la création post-validation : demande → e-mail → reset (#127). Tokens durcis (#123).
### 5.3 Création dossier staff
- Famille : wizard + `POST` staff parent/dossier (#129).
- AM : wizard + API staff AM (#156).
- Édition : mode `edit` wizards + PATCH fiches ; ajout co-parent `POST …/co-parent` (#135).
### 5.4 Rattachements
| Lien | Opérations |
|------|------------|
| Parent ↔ enfant | attach / detach (fiche parent, fiche enfant) |
| AM ↔ enfant | attach / detach (fiche AM, fiche enfant) ; UI capacité |
API : tickets #115 / #116 ; liste enfants enrichie #136.
---
## 6. Matrice droits × actions (synthèse)
| Action | gestionnaire | administrateur | super_admin |
|--------|:------------:|:--------------:|:-----------:|
| Voir dashboard usagers / dossiers | ✓ | ✓ | ✓ |
| Valider / refuser dossier | ✓ | ✓ | ✓ |
| Créer dossier parent / AM | ✓ | ✓ | ✓ |
| Éditer fiches parent / AM / enfant | ✓ | ✓ | ✓ |
| Rattacher / détacher enfant | ✓ | ✓ | ✓ |
| GET liste relais (combo) | ✓ | ✓ | ✓ |
| Créer gestionnaire / admin | ✗ | ✓ | ✓ |
| Supprimer parent / AM / enfant / dossier | ✓ | ✓ | ✓ |
| Supprimer gestionnaire | ✗ | ✓ | ✓ |
| Supprimer admin (garde-fous) | ✗ | ✓* | ✓* |
| Supprimer super_admin | ✗ | ✗ | ✗ |
| Supprimer son propre compte staff | ✗ | ✗ | ✗ |
\* Voir `canDeleteAdministrateur` / messages `adminDeleteBlockedReason`.
---
## 7. UI staff (points dentrée code)
| Zone | Emplacement typique |
|------|---------------------|
| Panneau gestion users | `widgets/dashboard/user_management_panel.dart` |
| Onglets parents / AM / enfants / dossiers | `widgets/dashboard/*_management_widget.dart` |
| Fiche parent | `parent_edit_modal.dart` |
| Fiche AM | `am_edit_modal.dart` |
| Fiche enfant | `child_detail_modal.dart` |
| Wizards dossier | `parent_dossier_wizard.dart`, `am_dossier_wizard.dart` |
| Modale staff | `staff_user_form_modal.dart` (`StaffUserFormModal`) |
| Confirm suppressions | `widgets/dashboard/common/suppression_confirm_dialog.dart` |
| Champs contrôlés | `validation_detail_section.dart` (`ValidationEmailField`, `ValidationPhoneField`…) |
| Thème primaire modales | `validation_modal_theme.dart` |
Shell fiches / wizards : largeur **930**, labels au-dessus, primaire violet `ValidationModalTheme`.
---
## 8. API — groupes (renvoi)
Ne pas dupliquer OpenAPI ici. Groupes utiles au domaine :
| Groupe | Exemples dusage |
|--------|------------------|
| Auth / register | Inscription parent & AM, login, tokens MDP, oubli MDP |
| Dossiers | `GET /dossiers/:numero`, listes à valider / unifiées, validate/refuse |
| Parents | Fiche PATCH, co-parent POST, dossier staff POST |
| AM | Fiche PATCH, dossier staff POST |
| Enfants | CRUD staff, attach/detach parent & AM |
| Users / staff | CRUD gestionnaires / admins, DELETE métier |
| Relais | `GET /relais` (autorisé gestionnaire — #151) |
| Config | setup / configuration instance |
Référence : [11_API.md](./11_API.md) (à maintenir en parallèle si écart).
---
## 9. Exigences non fonctionnelles (domaine users)
| ID | Exigence |
|----|----------|
| NFR-U1 | Tokens création / reset MDP : TTL strict, usage unique |
| NFR-U2 | Mots de passe : politique min. longueur (création staff / usager selon flux) |
| NFR-U3 | E-mails métier (validation, refus, MDP) via config SMTP instance |
| NFR-U4 | Pas de login si `en_attente` ou `suspendu` |
| NFR-U5 | Confirmations explicites avant toute suppression |
| NFR-U6 | Champs e-mail / téléphone : validation & normalisation côté UI staff (SRS UX #164) |
Hors scope immédiat : normalisation erreurs auth globale (#121), observabilité (#122), audit trail complet (#128).
---
## 10. Limites modèle famille (assumées)
Documentées pour les développeurs — détail produit : [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).
- Un `numero_dossier` / user ; un seul co-parent.
- Familles recomposées multi-contextes : contournement (2ᵉ compte / composition staff) jusqu’à epic #139.
- La SRS **nexige pas** N responsables en v0.1.0.
---
## 11. Traçabilité livré 0.1.0
Source : [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) — 48 tickets milestone 0.1.0 (auth, inscription, fiches, dossiers, suppressions, cleanups #152/#155/#162/#164).
---
## 12. Hors périmètre de cette SRS
- Contrats, avenants, fin de contrat (restent dans le **CDC** cible)
- Messagerie, agenda, événements RPE (idem CDC)
- Paie / Pajemploi
- Recherche AM côté parent
- PRA, CI/CD, monitoring infra
- Spécification OpenAPI ligne à ligne
- Texte fonctionnel complet → [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md)
-8
View File
@@ -1,8 +0,0 @@
# Fichier déplacé
La documentation **Documents légaux** a été déplacée vers :
**[juridique/22_DOCUMENTS-LEGAUX.md](./juridique/22_DOCUMENTS-LEGAUX.md)**
Voir aussi le dossier **[juridique/](./juridique/)** pour les sources **CGU**
et **CGC** en Markdown.
+14
View File
@@ -0,0 +1,14 @@
# Suivi des tickets — P'titsPas
**Source de vérité** : [Gitea — issues](https://git.ptits-pas.fr/jmartin/petitspas/issues)
**Milestones / versions** : [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)
**API Gitea** : [26_GITEA-API.md](./26_GITEA-API.md)
Ne plus maintenir de catalogue exhaustif des tickets dans le dépôt : l’état (ouvert / fermé / milestone) change dans Gitea.
Pour une **version livrée**, lire le bilan correspondant (ex. [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md)).
**Backlog en cours `0.2.0` (quotidien)** : epic [#165](https://git.ptits-pas.fr/jmartin/petitspas/issues/165) · [découpage #166#189](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md) · [mini-spec](./31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md).
Archive historique (liste Phase 1 figée, avril 2026) :
[archive/obsolete/23_LISTE-TICKETS.md](./archive/obsolete/23_LISTE-TICKETS.md).
+37 -30
View File
@@ -1,7 +1,7 @@
# 📋 Décisions Projet - P'titsPas # 📋 Décisions Projet - P'titsPas
**Version** : 1.2 **Version** : 1.3
**Date** : 16 Juin 2026 **Date** : 24 Septembre 2026
**Auteur** : Équipe PtitsPas **Auteur** : Équipe PtitsPas
--- ---
@@ -423,31 +423,23 @@ ptitspas-app/
- Maintenance (tout au même endroit) - Maintenance (tout au même endroit)
- Versioning (Git) - Versioning (Git)
**Structure** : **Structure** (sept. 2026) :
``` ```
docs/ docs/
├── 00_INDEX.md ├── 00_INDEX.md
├── 01_CAHIER-DES-CHARGES.md ├── 01_CAHIER-DES-CHARGES.md # V1.4 fonctionnel
├── 02_ARCHITECTURE.md ├── 05_VERSIONS-ET-MILESTONES.md
├── 03_DEPLOYMENT.md ├── 12_SRS-GESTION-UTILISATEURS.md
├── 10_DATABASE.md ├── 23_SUIVI-TICKETS.md
├── 11_API.md
├── 20_WORKFLOW-CREATION-COMPTE.md
├── 21_CONFIGURATION-SYSTEME.md
├── 22_DOCUMENTS-LEGAUX.md # pointeur → juridique/
├── 27_BRIEFING-FRONTEND.md
├── PROCEDURE-API-GITEA.md # pointeur → 26_GITEA-API.md
├── juridique/
│ ├── README.md
│ ├── cgu.md
│ ├── cgc.md
│ └── 22_DOCUMENTS-LEGAUX.md
├── archive/
│ ├── README.md
│ ├── temporaires/
│ └── obsolete/
├── 23_LISTE-TICKETS.md
├── 24_DECISIONS-PROJET.md (ce document) ├── 24_DECISIONS-PROJET.md (ce document)
├── 26_GITEA-API.md
├── 27_BRIEFING-FRONTEND.md
├── 28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md
├── 29_BILAN-VERSION-0.1.0.md
├── 99_REGLES-CODAGE.md
├── CHARTE_GRAPHIQUE.md
├── juridique/ # CGU + 22_DOCUMENTS-LEGAUX.md
├── archive/ # obsolete / temporaires
├── 90_AUDIT.md ├── 90_AUDIT.md
└── test-data/ └── test-data/
``` ```
@@ -473,19 +465,34 @@ docs/
--- ---
### 26. Branches Git ### 26. Branches Git + merge squash (norme)
**Décision** : ✅ **Stratégie simple : master + feature branches** **Décision** : ✅ **`develop` + `master` + `feature/*`, merges en squash**
**Justification** : **Justification** :
- Simplicité (petite équipe) - Simplicité (petite équipe)
- Flexibilité - Historique lisible sur `develop` / `master` (1 commit = 1 ticket)
- Déploiement prod uniquement depuis `master`
**Branches** : **Branches** :
- `master` : Production - `master` : Production (déploiement auto)
- `archive/*` : Archives (ex: maquette initiale) - `develop` : Intégration / recette
- `migration/*` : Migrations (ex: intégration YNOV) - `feature/*` : Ticket en cours (depuis `develop`)
- `feature/*` : Nouvelles fonctionnalités - `archive/*`, `migration/*` : Archives / migrations ponctuelles
**Flux (norme à partir de #169+)** :
1. Branche `feature/N-…` depuis `develop`
2. PR **feature → `develop`** : merge **squash** (`Do: squash` côté Gitea)
3. Quand un lot est prêt : PR **`develop``master`** : merge **squash** également
4. Message squash : `feat(#N): …` / `fix(#N): …` + `Closes #N` si applicable
**Exception** : les merges `--no-ff` déjà poussés (ex. #167, #168) restent tels quels — pas de réécriture dhistorique.
**API Gitea** (rappel) :
```http
POST /repos/jmartin/petitspas/pulls/{index}/merge
{"Do":"squash","MergeTitleField":"feat(#N): …","MergeMessageField":"Closes #N"}
```
--- ---
+8 -1
View File
@@ -116,10 +116,17 @@ curl -s -H "Authorization: token $GITEA_TOKEN" \
"https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls?state=open" | jq . "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls?state=open" | jq .
# Créer une PR (head = branche source, base = branche cible) # Créer une PR (head = branche source, base = branche cible)
# Norme : feature/* → develop, puis develop → master
curl -s -X POST -H "Authorization: token $GITEA_TOKEN" \ curl -s -X POST -H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \ -H "Content-Type: application/json" \
-d '{"head":"develop","base":"master","title":"Titre de la PR"}' \ -d '{"head":"feature/XX-nom","base":"develop","title":"feat(#XX): Titre","body":"Closes #XX"}' \
"https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls" "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls"
# Merger en squash (norme — voir 24_DECISIONS-PROJET.md §26)
curl -s -X POST -H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"Do":"squash","MergeTitleField":"feat(#XX): Titre","MergeMessageField":"Closes #XX"}' \
"https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls/{index}/merge"
``` ```
### 3.4 Branches ### 3.4 Branches
+14 -4
View File
@@ -194,6 +194,9 @@ frontend/lib/
## Workflow Git ## Workflow Git
Norme projet : **squash merge** (voir [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md) §26).
Cible habituelle : `feature/*``develop` ; puis `develop``master` quand le lot est prêt.
```bash ```bash
# 1. Créer une branche feature # 1. Créer une branche feature
git checkout develop git checkout develop
@@ -204,15 +207,22 @@ git checkout -b feature/XX-nom-ticket
git add . git add .
git commit -m "feat(#XX): Description courte" git commit -m "feat(#XX): Description courte"
# 3. Pousser et créer PR # 3. Pousser et créer PR vers develop
git push -u origin feature/XX-nom-ticket git push -u origin feature/XX-nom-ticket
# 4. Créer PR vers master via Gitea ou API # 4. Créer PR (base = develop)
curl -X POST \ curl -X POST \
-H "Authorization: token giteabu_1796c6aace0e2ef7e4fdb49cdc3bc1bf8ee31fbc" \ -H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \ -H "Content-Type: application/json" \
-d '{"title":"feat(#XX): Titre","body":"Description\n\nCloses #XX","head":"feature/XX-nom-ticket","base":"master"}' \ -d '{"title":"feat(#XX): Titre","body":"Description\n\nCloses #XX","head":"feature/XX-nom-ticket","base":"develop"}' \
"https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls" "https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls"
# 5. Merger en squash (pas merge commit)
curl -X POST \
-H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"Do":"squash","MergeTitleField":"feat(#XX): Titre","MergeMessageField":"Closes #XX"}' \
"https://git.ptits-pas.fr/api/v1/repos/jmartin/petitspas/pulls/{index}/merge"
``` ```
--- ---
+3 -1
View File
@@ -3,7 +3,9 @@
**Version** : 1.1 **Version** : 1.1
**Date** : 16 juin 2026 **Date** : 16 juin 2026
**Statut** : Réflexions produit / architecture — complément au [CDC](./01_CAHIER-DES-CHARGES.md) **Statut** : Réflexions produit / architecture — complément au [CDC](./01_CAHIER-DES-CHARGES.md)
**Documents liés** : [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) **Documents liés** : [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) (V1.4), [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md), [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md)
**Archive** : ancien patch CDC → [archive/obsolete/EVOLUTIONS_CDC.md](./archive/obsolete/EVOLUTIONS_CDC.md)
--- ---
+197
View File
@@ -0,0 +1,197 @@
# Bilan — Version 0.1.0
**Statut** : terminée
**Milestone Gitea** : [0.1.0](https://git.ptits-pas.fr/jmartin/petitspas/milestone/10)
**Dépôt** : `jmartin/petitspas`
**Tag prévu** : `v0.1.0` (sur `master` après merge de cette doc)
Ce document est la **mémoire produit** de la version 0.1.0 : ce qui a été livré, ticket par ticket, et ce qui a été reporté.
---
## 1. Périmètre produit livré
La 0.1.0 couvre le **MVP opérable** pour une collectivité :
- Authentification, création / oubli de mot de passe, e-mails associés
- Inscription parent & AM, validation / refus gestionnaire, reprise après refus
- Dashboard staff (admin + gestionnaire) : listes, fiches, rattachements
- Onglet **Dossiers** + wizards création / édition (famille & AM)
- Suppressions métier (droits, confirms, cascades API)
- Cleanups structurels (préfixe `Admin*`, panels dashboard, modale staff, retrait `est_multiple`)
**Hors 0.1.0** (reporté) : doublons avancés, famille N responsables, statut enfant gardé/sans garde, combobox RPE AM, chantier CDC (#117), tickets tech/observabilité — voir §4 et [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
---
## 2. Thèmes livrés
### 2.1 Auth, mot de passe, e-mails
| # | Titre | Livré |
|---|-------|--------|
| 24 | API Création mot de passe | Endpoints token → création MDP post-validation |
| 28 | Templates Email — Validation | Mails validation avec lien MDP |
| 30 | Connexion — Vérification statut | Blocage comptes pending / suspendus à la connexion |
| 43 | Écran Création Mot de Passe | UI lien e-mail création MDP |
| 47 | Écran Changement MDP Obligatoire | Première connexion staff |
| 50 | Affichage dynamique CGU | CGU/Privacy versionnées à linscription |
| 118 | Page création mot de passe (Front + API) | Alignement front/API du flux lien e-mail |
| 123 | Durcissement token création MDP | TTL, usage unique, contrôles API |
| 127 | Mot de passe oublié | Demande → e-mail → réinitialisation (flux distinct de #24/#43) |
### 2.2 Inscription, numéros de dossier, reprise
| # | Titre | Livré |
|---|-------|--------|
| 104 | Numéro de dossier — frontend | Affichage listes / mails / modales ; format AAAA-… |
| 112 | Reprise après refus — frontend | Lien e-mail `/reprise` + reprise par n° dossier |
| 120 | Inscription AM — photo & UX | Chaîne photo / API / UX alignée parents |
| 144 | Consentement photo enfant | Persistance du consentement à linscription |
### 2.3 Dashboard — fiches, listes, rattachements
| # | Titre | Livré |
|---|-------|--------|
| 115 | Rattachement enfants — backend | Attach/detach parent↔enfant et AM↔enfant |
| 116 | Rattachement enfants — frontend | UI fiches parent / AM |
| 130 | UserService — APIs métier | Branchement parents / AM / enfants côté front |
| 131 | Édition fiche parent + AM | Modales édition dashboard |
| 132 | Création enfant (onglet Enfants) | Création + rattachement foyer |
| 136 | API enfants — droits & liste | Droits gestionnaire + enrichissement liste |
| 137 | Onglet Enfants — liste globale | Panneau liste dashboard |
| 138 | Fiche enfant + liste dans parent | Fiche enfant ; enfants dans fiche parent |
| 140 | Epic fiche parent / affiliation | Livraison regroupée dashboard admin/gestionnaire |
| 142 | Clic carte → modale | Ouverture fiche depuis les listes |
| 145 | Lien co-parent cliquable | Navigation fiche parent → co-parent |
| 146 | Modale sélection enfant | UX rattacher enfant (AM + parent) |
| 147 | Modale sélection AM | UX rattacher AM depuis fiche enfant |
| 148 | Capacité max AM | Désactivation rattachement si capacité atteinte |
| 149 | Case libre AM → rattacher | Clic emplacement vide pour rattacher |
| 151 | GET /relais pour gestionnaire | Combo relais dans modale staff |
| 157 | Enfant sans responsable | Détachement dernier parent + alerte liste |
| 158 | Affiliation foyer (pivot + co-parent) | Attach/detach cohérents sur le foyer |
### 2.4 Dossiers staff (création, édition, liste)
| # | Titre | Livré |
|---|-------|--------|
| 129 | Création dossier parent | Wizard + API staff famille |
| 135 | Édition dossier + 2ᵉ parent | Mode edit wizards + `POST …/co-parent` |
| 153 | Onglet Dossiers | Liste unifiée + à valider (sans création dans longlet) |
| 156 | Création dossier AM | Wizard + API staff AM |
### 2.5 Suppressions & droits staff
| # | Titre | Livré |
|---|-------|--------|
| 133 | Suppression parent + AM (UI) | Première vague UI (complétée par #160) |
| 134 | Droits « Ajouter gestionnaire » | Visibilité / API selon rôle |
| 143 | Bug supprimer sa propre fiche | Masquage / interdiction auto-suppression |
| 154 | Epic suppressions | Cadrage règles métier suppressions |
| 159 | Suppressions métier — backend | Cascades, garde-fous, droits API |
| 160 | Suppressions dashboard — frontend | Poubelles + dialogues de confirmation |
| 161 | Admin création staff 403 | Admin peut créer gestionnaire et administrateur |
### 2.6 Cleanups structure & UX
| # | Titre | Livré |
|---|-------|--------|
| 25 | API Liste comptes en attente | Historique ; couvert par flux dossiers / validation |
| 26 | API Validation / Refus | Historique ; couvert par flux dossiers / validation |
| 152 | Retrait `est_multiple` | Suppression full stack (BDD, API, front, docs) |
| 155 | Rename préfixe `Admin*` | Widgets partagés sans préfixe Admin (option C) |
| 162 | Panels → `widgets/dashboard/` | Suite #155 — panels staff sous dashboard |
| 164 | Modale staff uniformisée | `StaffUserFormModal` (shell 930, champs contrôlés) |
---
## 3. Inventaire exhaustif (48 tickets fermés, milestone 0.1.0)
| # | Titre |
|---|-------|
| 24 | [Backend] API Création mot de passe |
| 25 | [Backend] API Liste comptes en attente |
| 26 | [Backend] API Validation/Refus comptes |
| 28 | [Backend] Templates Email - Validation |
| 30 | [Backend] Connexion - Vérification statut |
| 43 | [Frontend] Écran Création Mot de Passe |
| 47 | [Frontend] Écran Changement MDP Obligatoire |
| 50 | [Frontend] Affichage dynamique CGU lors inscription |
| 104 | Numéro de dossier frontend |
| 112 | Reprise après refus frontend |
| 115 | [Backend] Rattachement enfants — parent et AM |
| 116 | [Frontend] Rattachement enfants — parent et AM |
| 118 | Page création mot de passe (lien email) Front + API |
| 120 | [Full-stack] Inscription AM — photo, API et UX alignés sur les parents |
| 123 | [Tech] Durcissement token création MDP |
| 127 | [Full-stack] Mot de passe oublié — flux complet |
| 129 | Création dossier parent (wizard + API staff) |
| 130 | [Frontend] UserService — brancher APIs parents, AM et enfants |
| 131 | [Frontend] Édition fiche parent + AM |
| 132 | Création enfant depuis longlet Enfants |
| 133 | [Frontend] Suppression compte parent + AM |
| 134 | Droits bouton « Ajouter gestionnaire » |
| 135 | Mode édition dossier (+ ajout 2ᵉ parent) |
| 136 | [Backend] API enfants — droits gestionnaire + enrichissement liste |
| 137 | [Frontend] Onglet Enfants — liste globale |
| 138 | [Frontend] Fiche enfant + liste enfants dans fiche parent |
| 140 | Dashboard admin — fiche parent, enfants et affiliation |
| 142 | Clic sur carte → ouvrir la modale |
| 143 | Bug — Gestionnaire Supprimer sur sa propre fiche |
| 144 | Bug — Consentement photo enfant non sauvegardé |
| 145 | Lien co-parent cliquable |
| 146 | UX — modale sélection d'enfant |
| 147 | UX — modale sélection d'AM |
| 148 | Bug — capacité max AM |
| 149 | Fiche AM — clic case libre pour rattacher |
| 151 | Bug — GET /relais gestionnaire |
| 152 | Cleanup — supprimer `est_multiple` |
| 153 | Onglet permanent « Dossiers » |
| 154 | Epic — suppressions utilisateurs / dossiers / enfants / AM |
| 155 | Cleanup — renommer préfixe Admin* |
| 156 | Création dossier AM (wizard + API staff) |
| 157 | Enfant sans responsable |
| 158 | Affiliation enfant au foyer (pivot + co-parent) |
| 159 | Backend suppressions métier (#154) |
| 160 | Frontend suppressions dashboard (#154) |
| 161 | Bug — Admin création gestionnaire / administrateur |
| 162 | Cleanup — panels vers `widgets/dashboard/` |
| 164 | Uniformisation modale staff + champs contrôlés |
Issues : https://git.ptits-pas.fr/jmartin/petitspas/issues?q=&type=all&state=closed&labels=&milestone=10&assignee=0
---
## 4. Reporté hors 0.1.0
| # | Titre | Destination typique |
|---|-------|---------------------|
| 113 / 114 | Doublons inscription / alerte gestionnaire | 0.9.0 |
| 117 | Évolution du cahier des charges | Doc (amendement CDC post-0.1.0) |
| 121122, 124125 | Tech auth / photos / DB | 0.9.0 |
| 126 | Upload documents légaux 500 | 0.9.0 |
| 128 | Audit / traçabilité modifications | 0.9.0 |
| 139 | Famille complexe N responsables | Post-0.1.0 / epic |
| 141 | Statut enfant gardé / sans garde | Post-0.1.0 |
| 150 | Combobox rattachement RPE (AM) | 0.2.0 |
Voir aussi [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
---
## 5. Suite documentaire
1. **Amendement CDC (#117)** — CDC V1.4 : mise à jour **gestion utilisateurs** ; le reste du CDC reste la cible. SRS technique : [12_SRS-GESTION-UTILISATEURS.md](./12_SRS-GESTION-UTILISATEURS.md). Intrants historiques archivés : [archive/obsolete/EVOLUTIONS_CDC.md](./archive/obsolete/EVOLUTIONS_CDC.md), [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).
2. **Tag** `v0.1.0` sur `master` lorsque milestone fermée + ce bilan mergé.
3. Enchaîner les milestones **0.2.0+** selon [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md).
---
## 6. Références code (points dentrée)
- Modale staff : `frontend/lib/widgets/dashboard/staff_user_form_modal.dart`
- Fiches : `parent_edit_modal.dart`, `am_edit_modal.dart`, `child_detail_modal.dart`
- Wizards dossiers : `parent_dossier_wizard.dart`, `am_dossier_wizard.dart`
- Règles suppressions : tickets #154 / #159 / #160
- Cleanup `est_multiple` : #152
+201
View File
@@ -0,0 +1,201 @@
# Découpage tickets — Quotidien parent / AM
> **Statut :** backlog Gitea créé (**milestone `0.2.0`**, **#165#189**) — *création anticipée avant validation PO* ; **descriptions enrichies** ensuite à partir de la mini-spec / découpage.
> **Réf. visuelle :** [maquettes/courantes/maquette-dashboard-parent-quotidien-v4.png](./maquettes/courantes/maquette-dashboard-parent-quotidien-v4.png)
> **Mini-spec :** [31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md](./31_MINI-SPEC-QUOTIDIEN-PARENT-AM.md)
> **Règle :** tickets **front** / **back** séparés · widgets partagés parent↔AM · **pas dimplé code** tant que le PO na pas validé le backlog.
## Intention produit (rappel)
- TdB PC en **3 colonnes** : **cartes** | **blog** (défaut) | **messagerie**
- Contexte actif = **couple** enfantnounou (parent) / enfantparent(s) (AM)
- Blog **indispensable** (AM + RPE) ; messagerie type WhatsApp (BABA, 2 parents = même fil AM)
- Look **papier / pastel / lignée inscription** (pas le dashboard staff)
- **Widgets partagés** parent ↔ AM (blog, messagerie, cartes, coquille, couple paramétré) — pas de double implémentation
- « Effet démo » = logiciel peuplé + sync live multi-écrans — **pas** un sous-MVP jetable
- **Hors ce découpage** (jalons suivants) : page Contrat riche (Pajemploi, CP), notifs CDC fourre-tout, masquage messages, posts blog parent, Agenda « riche » (entrée bandeau possible en stub)
## Contrainte technique front (dictée 23/09)
Les panneaux parent et AM étant **quasiment identiques**, le découpage impose des **briques réutilisables** :
| Widget / module | Tickets concernés |
|-----------------|-------------------|
| Coquille TdB 3 colonnes + bandeau | A1, B1 — B1 **réutilise** la coquille dA1 |
| Sélecteur couple (mode parent vs AM) | A2, B2 — **un** composant, 2 modes |
| Flux de cartes | C2, C3 — **un** widget + config rôles |
| Blog (fil + composeur) | D2, D3, D4 — même brique |
| Messagerie (chat + onglets) | E4, E5, E6 — même brique |
Les tickets **[Front] AM** (B1, B2, C3, D3, E5) = **intégration / mode rôle**, pas une 2ᵉ copie du code.
## Proposition de milestone
| Champ | Valeur |
|-------|--------|
| Titre | **`0.2.0`** (rouvert) |
| Description | Quotidien parent / AM — TdB 3 colonnes, cartes, blog, messagerie |
| Label | `v0.2.0` |
## Mapping Gitea
| Id | Issue | Titre |
|----|-------|-------|
| Epic | [#165](https://git.ptits-pas.fr/jmartin/petitspas/issues/165) | Epic quotidien |
| A1 | [#166](https://git.ptits-pas.fr/jmartin/petitspas/issues/166) | [Front] Coquille TdB parent |
| A2 | [#167](https://git.ptits-pas.fr/jmartin/petitspas/issues/167) | [Front] Couple enfantnounou |
| A3 | [#168](https://git.ptits-pas.fr/jmartin/petitspas/issues/168) | [Backend] API couples parent |
| B1 | [#169](https://git.ptits-pas.fr/jmartin/petitspas/issues/169) | [Front] Coquille TdB AM |
| B2 | [#170](https://git.ptits-pas.fr/jmartin/petitspas/issues/170) | [Front] Couple enfantparent(s) |
| B3 | [#171](https://git.ptits-pas.fr/jmartin/petitspas/issues/171) | [Backend] API enfants AM |
| C1 | [#172](https://git.ptits-pas.fr/jmartin/petitspas/issues/172) | [Backend] API cartes |
| C2 | [#173](https://git.ptits-pas.fr/jmartin/petitspas/issues/173) | [Front] Cartes parent |
| C3 | [#174](https://git.ptits-pas.fr/jmartin/petitspas/issues/174) | [Front] Cartes AM |
| C4 | [#175](https://git.ptits-pas.fr/jmartin/petitspas/issues/175) | [Front] Déclarer absence |
| C5 | [#176](https://git.ptits-pas.fr/jmartin/petitspas/issues/176) | [Front] Formulaires AM cartes |
| D1 | [#177](https://git.ptits-pas.fr/jmartin/petitspas/issues/177) | [Backend] API blog |
| D2 | [#178](https://git.ptits-pas.fr/jmartin/petitspas/issues/178) | [Front] Blog parent |
| D3 | [#179](https://git.ptits-pas.fr/jmartin/petitspas/issues/179) | [Front] Blog AM |
| D4 | [#180](https://git.ptits-pas.fr/jmartin/petitspas/issues/180) | [Front] Blog gestionnaire |
| E1 | [#181](https://git.ptits-pas.fr/jmartin/petitspas/issues/181) | [Backend] Socle messagerie |
| E2 | [#182](https://git.ptits-pas.fr/jmartin/petitspas/issues/182) | [Backend] Mess. AM |
| E3 | [#183](https://git.ptits-pas.fr/jmartin/petitspas/issues/183) | [Backend] Mess. RPE |
| E4 | [#184](https://git.ptits-pas.fr/jmartin/petitspas/issues/184) | [Front] Messagerie parent |
| E5 | [#185](https://git.ptits-pas.fr/jmartin/petitspas/issues/185) | [Front] Messagerie AM |
| E6 | [#186](https://git.ptits-pas.fr/jmartin/petitspas/issues/186) | [Front] Mess. RPE gestionnaire |
| F1 | [#187](https://git.ptits-pas.fr/jmartin/petitspas/issues/187) | [Front] Stubs Agenda / Contrat |
| F2 | [#188](https://git.ptits-pas.fr/jmartin/petitspas/issues/188) | [Front] Swipe mobile |
| G1 | [#189](https://git.ptits-pas.fr/jmartin/petitspas/issues/189) | [Backend] Seeds quotidien |
---
## Epic A — Coquille TdB parent
### A1 — [Front] Coquille TdB parent 3 colonnes + bandeau → [#166](https://git.ptits-pas.fr/jmartin/petitspas/issues/166)
Bandeau TdB / Agenda / Contrat + menu user ; corps en 3 colonnes (cartes | blog | messagerie) ; fond papier / pastel. **Livrer la coquille comme widget/layout réutilisable** (lAM B1 sen branche). Remplace / refactor `ParentDashboardScreen` + `dashbord_parent/`.
### A2 — [Front] Sélecteur couple enfantnounou → [#167](https://git.ptits-pas.fr/jmartin/petitspas/issues/167)
Composant **paramétrable** (mode parent : enfant|nounou). Dropdown si plusieurs gardes ; informatif si une seule. B2 = même widget en mode AM.
### A3 — [Back] API contexte de garde actif (couples parent)
Endpoint(s) listant les couples enfantAM du parent connecté + couple « courant » (persistance session / préférence). Données mini : ids, noms, photos.
---
## Epic B — Coquille TdB AM (miroir)
### B1 — [Front] Coquille TdB AM 3 colonnes + bandeau → [#169](https://git.ptits-pas.fr/jmartin/petitspas/issues/169)
**Réutilise** la coquille dA1/#166 ; point de départ `am_dashboard_screen.dart`.
### B2 — [Front] Sélecteur couple enfantparent(s) → [#170](https://git.ptits-pas.fr/jmartin/petitspas/issues/170)
**Même widget** quA2 en mode AM : gauche photo enfant ; droite parent1+parent2 empilés ou un parent centré.
### B3 — [Back] API contexte enfants accueillis (AM)
Liste des enfants / foyers pour lAM + contexte courant (symétrique A3).
---
## Epic C — Cartes (file du quotidien)
### C1 — [Back] Modèle + API cartes / événements de garde
Types V1 : absence enfant, congé AM, maladie AM (« arrêt »), sortie à valider. CRUD / transitions de statut ; liaison couple / agenda (hook minimal). Règles : absence enfant sans veto AM ; congé AM accepter/refuser (**1 parent suffit**) ; maladie AM accusé parent ; sortie **1 parent suffit**. Aucun doc médical stocké.
### C2 — [Front] Flux de cartes colonne gauche (parent)
Liste scroll pastel (palette `assets/cards/` — 7 couleurs) ; ouverture détail ; actions valider / refuser / accusé selon type. Bouton **Déclarer une absence** (+ autres actions TBD plus tard).
### C3 — [Front] Flux de cartes colonne gauche (AM)
Miroir : création congé / maladie / sortie ; lecture absences enfants du jour / à venir.
### C4 — [Front] Formulaire déclarer une absence (parent)
Saisie période (+ motif léger si besoin) → crée une carte côté AM.
### C5 — [Front] Formulaires AM congé / maladie / sortie
Création des cartes correspondantes + ciblage enfants si sortie.
---
## Epic D — Blog
### D1 — [Back] Modèle + API blog (posts + médias)
Posts par auteur AM ou gestionnaire (RPE) ; texte + photos ; ciblage enfants (AM) / audience (RPE) ; fil visible parents (et AM selon règles). Sync temps réel ou polling acceptable V1.
### D2 — [Front] Colonne Blog parent (défaut)
Fil de posts ; auteur **distinct** AM vs RPE ; miniatures ; pas de bouton « Écrire un post » parent en V1 (reporté).
### D3 — [Front] Colonne Blog AM — lecture + écrire un post
Composer texte + photos + sélection enfants concernés ; publication.
### D4 — [Front] Publication blog gestionnaire (point dentrée staff)
UI minimale côté dashboard gestionnaire (ou réutilisation) pour publier une annonce RPE visible sur les TdB parent/AM.
---
## Epic E — Messagerie
### E1 — [Back] Socle messagerie (choix lib / protocole) + API
Évaluer brique existante (style chat WhatsApp : texte, emoji, images). Conversations, participants, pièces jointes images. Temps réel (WS ou équivalent) souhaité pour leffet multi-écrans.
### E2 — [Back] Mess. AM — conversation foyer ↔ AM
Une conversation par couple/foyer ; **les deux parents** voient le **même** fil. Pas de masquage V1.
### E3 — [Back] Mess. RPE — privée + ajout de participants
Fil 1↔1 par défaut (parent↔RPE ou AM↔RPE) ; possibilité d**ajouter** 2ᵉ parent / AM / parent pour médiation.
### E4 — [Front] Colonne messagerie parent (onglets Mess. AM | Mess. RPE)
UI chat + saisie + PJ ; défaut = Mess. AM.
### E5 — [Front] Colonne messagerie AM (onglets équivalents)
Miroir parent ; Mess. AM = foyer courant ; Mess. RPE = canal relais.
### E6 — [Front] Mess. RPE côté gestionnaire (entrée minimale)
Liste / réponse aux fils RPE + ajout de participants pour médiation.
---
## Epic F — Navigation & mobile (socle)
### F1 — [Front] Navigation Agenda / Contrat (stubs ou routes)
Entrées bandeau : pages **placeholder** ou squelette (Agenda / Contrat pleine page) pour ne pas bloquer le TdB — contenu métier = jalons suivants.
### F2 — [Front] Adaptation mobile — swipe 3 panneaux
Sur téléphone : swipe Blog ↔ Cartes ↔ Messagerie ; navigation TdB/Agenda/Contrat hors swipe. Contrat peut rester limité (« mieux sur PC ») en V1 si besoin.
---
## Epic G — Données de démo / peuplement
### G1 — [Back/Outillage] Jeu de données peuplé quotidien
Scripts / seeds : foyer 2 parents, AM, enfant(s), quelques cartes, posts blog, fils messagerie — pour enchaîner une démo multi-écrans sans saisie manuelle lourde.
---
## Hors découpage (volontairement)
| Sujet | Motif |
|-------|--------|
| Page Contrat (Pajemploi, CP, avenants) | Module valué — jalon dédié |
| Agenda calendrier riche | Entrée bandeau OK en stub ; métier plus tard |
| Notifs CDC (contrat/paiement/dossier) | Plus tard |
| Masquage messages / privé parent↔AM | Plus tard |
| Parent auteur de posts blog | Hypothétique / plus tard |
| Photo parent à linscription | Non ; éventuel menu profil plus tard |
---
## Ordre de réalisation suggéré
1. **A1 → A2 → A3** (coquille + contexte parent)
2. **C1 → C2 / C4** (premières cartes utiles)
3. **D1 → D2 / D3** (blog central)
4. **E1 → E2 → E4** (messagerie AM)
5. **B1 → B2 → B3** + miroirs C3/C5/D3/E5 (AM)
6. **E3 / E5 / E6 / D4** (RPE)
7. **F1 → F2** + **G1** (nav, mobile, seeds)
---
## Validation
Backlog créé sur Gitea (**#165#189**, milestone `0.2.0`).
**Implémentation code** : seulement après relecture PO / ajustements éventuels sur le découpage.
+104
View File
@@ -0,0 +1,104 @@
# Mini-spec — Quotidien parent / AM
> **Statut :** figée pour backlog (sept. 2026)
> **Réf. visuelle :** [maquettes/courantes/maquette-dashboard-parent-quotidien-v4.png](./maquettes/courantes/maquette-dashboard-parent-quotidien-v4.png)
> **Découpage tickets :** [30_DECOUPAGE-TICKETS-QUOTIDIEN.md](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md)
> **CDC :** vision dorigine conservée ; priorités UX évoluées (blog central, couple enfantnounou)
## 1. Objectif
Construire les **espaces parent et AM du quotidien** : tableau de bord 3 colonnes, file de cartes (absences / congés / sorties), **blog** (cœur du jour), **messagerie** AM et RPE. Logiciel réel peuplé de données ; une démo = sync live multi-écrans (parent / AM / gestionnaire).
## 2. UI — contrainte non négociable
- Look **papier / pastel**, lignée **login / inscription** (`paper2.png`), pas le dashboard staff violet Material
- PC paysage : **3 colonnes** égales
- Mobile : **swipe** entre les 3 panneaux ; TdB / Agenda / Contrat via nav dédiée
### Architecture front — maximiser les widgets partagés
Parent et AM sont **quasi identiques** : **ne pas dupliquer** les colonnes métier.
| Brique | Usage |
|--------|--------|
| Widget **Blog** | Colonne milieu parent **et** AM (+ entrée publication gestionnaire qui réutilise le composeur) |
| Widget **Messagerie** | Colonne droite parent **et** AM (+ vue gestionnaire RPE) |
| Widget **flux de cartes** | Colonne gauche parent **et** AM (actions / droits selon rôle) |
| Widget **bandeau couple** | Variante *enfant\|nounou* (parent) vs *enfant\|parent(s)* (AM) — même composant paramétré |
| Coquille TdB 3 colonnes | Layout / bandeau navig commun ; le rôle injecte le couple + droits |
Principe : **briques correctement encapsulées** (API claire props / callbacks), branchées sur le même back ; seules les **différences de rôle** (qui crée quoi, libellés daction) restent hors du widget partagé.
## 3. Layout TdB
| Colonne | Contenu |
|---------|---------|
| **Gauche** | Couple actif · flux de **cartes** · actions (ex. Déclarer une absence) |
| **Milieu** | **Blog** — affichage **par défaut** à larrivée |
| **Droite** | **Messagerie** seule — onglets Mess. AM (défaut) \| Mess. RPE |
Bandeau : **TdB** · **Agenda** · **Contrat** · menu user (recherche AM, paramètres…).
### Parent — couple
- Un bandeau **enfant | nounou** (photos + noms)
- Plusieurs gardes → dropdown unique (bascule de couple)
- Une seule garde → affichage informatif (pas de chevron)
### AM — couple (miroir)
- Bandeau **enfant | parent(s)**
- 2 parents : noms empilés à droite ; 1 parent : nom centré
- Pas de photo parent obligatoire (option profil plus tard)
## 4. Canaux (ne pas mélanger)
| Canal | Rôle |
|-------|------|
| **Cartes** | Décisions / futur proche : absences, congés, maladie AM, sorties à valider |
| **Blog** | Mémoire / actus du quotidien (texte + photos) — **indispensable**, plus un module optionnel CDC §9 |
| **Mess. AM** | Chat foyer ↔ AM (style WhatsApp : texte, emoji, images) |
| **Mess. RPE** | Privée par défaut ; ajout de participants pour médiation / conflit |
## 5. Règles métier V1
| Type | Qui initie | Validation |
|------|------------|------------|
| Absence enfant | Parent | Pas de veto AM |
| Congé AM | AM | **1 parent** accepte ou refuse |
| Maladie AM | AM | Parent accuse réception (pas de doc médical in-app) |
| Sortie | AM / RPE | **1 parent** suffit (présence / absence) ; explication aussi via blog |
- Mess. AM : les **2 parents** voient le **même** fil — **pas** de masquage V1
- Blog auteurs V1 : **AM** + **gestionnaire (RPE)** — parent auteur = plus tard
- Couple actif filtre cartes + messagerie + blog (hypothèse produit : **oui**)
## 6. Hors périmètre de ce jalon
- Page **Contrat** riche (Pajemploi, CP…) — stub bandeau OK
- **Agenda** calendrier riche — stub bandeau OK
- Notifications CDC fourre-tout (paiement, dossier…)
- Masquage messages ; posts blog parent
- Carnet repas/sieste (roadmap Phase 4)
## 7. Critères « effet démo » (acceptation)
Avec données peuplées, sur au moins 2 supports :
1. Parent et AM voient le **même contexte de garde** (couple / enfant)
2. Parent déclare une **absence** → carte visible côté AM
3. AM publie un **post blog** (texte + photo) → visible colonne blog parent
4. Gestionnaire publie une **annonce RPE** → visible sur les TdB concernés
5. Message **Mess. AM** dun côté → apparaît de lautre (près temps réel)
6. Look conforme charte papier / pastel
## 8. Point de départ code
- Parent : `frontend/lib/screens/home/parent_screen/ParentDashboardScreen.dart` + `dashbord_parent/`
- AM : `frontend/lib/screens/am/am_dashboard_screen.dart` (placeholder)
- Cartes couleurs : `frontend/assets/cards/` (7 teintes max)
## 9. Ordre de build suggéré
Voir [30_DECOUPAGE-TICKETS-QUOTIDIEN.md](./30_DECOUPAGE-TICKETS-QUOTIDIEN.md) § ordre — A (coquille parent) → C (cartes) → D (blog) → E (messagerie) → B (miroir AM) → RPE → F/G (mobile + seeds).
-8
View File
@@ -1,8 +0,0 @@
# Fichier déplacé / fusionné
La procédure **API Gitea** est désormais documentée sous :
**[26_GITEA-API.md](./26_GITEA-API.md)**
Lancienne copie `PROCEDURE-API-GITEA.md` est archivée dans
`docs/archive/obsolete/` (doublon).
+8 -19
View File
@@ -1,30 +1,19 @@
# Archive documentation · P'titsPas # Archive documentation · P'titsPas
Ce dossier regroupe les fichiers **sans préfixe numérique** à la racine de Fichiers **hors références actives** : brouillons livrés, CDC historiques, listes figées.
`docs/` qui ne sont plus des **références actives**, ou qui sont des
**brouillons / temporaires**.
## Règle de nommage (racine `docs/`) ## Règle de nommage (racine `docs/`)
- Les documents **normatifs** à la racine portent un préfixe **`NN_`** - Documents **normatifs** : préfixe **`NN_`**.
(deux chiffres), ex. `23_LISTE-TICKETS.md`. - Exceptions héritage listées dans [00_INDEX.md](../00_INDEX.md) (`CHARTE_GRAPHIQUE.md`).
- **Exceptions** (héritage ou outillage) listées dans
[**00_INDEX.md**](../00_INDEX.md#exceptions-de-nommage) : charte, CDC
historique, évolutions — **cible** : les renommer progressivement en `NN_`
et mettre à jour `.cursorrules` / liens.
## Sous-dossiers ici ## Sous-dossiers
| Dossier | Usage | | Dossier | Usage |
|---------|--------| |---------|--------|
| [**temporaires/**](./temporaires/) | Notes jetables, exports de travail. | [**temporaires/**](./temporaires/) | Brouillons jetables. **Vider** dès livraison. |
**Supprimables** quand la tâche associée est close. | | [**obsolete/**](./obsolete/) | Doc remplacée (CDC SuperNounou, ancienne liste tickets, notes ponctuelles, backlog Phase 2 figé). |
| [**obsolete/**](./obsolete/) | Ancienne doc **remplacée** ou **doublon**
(conservée un temps pour historique). **Supprimer** après bascule confirmée
si plus aucune référence. |
## Hors `docs/` racine ## Politique `tmp/`
Les dossiers thématiques (**`juridique/`**, **`test-data/`**, etc.) peuvent Le dossier `docs/tmp/` **nest plus utilisé**. Les mini-specs de tickets livrés sont purgés ; la mémoire produit = bilans de version (`29_…`) + tickets Gitea.
contenir des fichiers sans `NN_` : la règle `NN_` sapplique surtout aux
fichiers **directement** sous `docs/`.
File diff suppressed because it is too large Load Diff
@@ -2,7 +2,9 @@
Ce document liste les modifications à apporter au cahier des charges original pour le rendre conforme à l'application développée. Ce document liste les modifications à apporter au cahier des charges original pour le rendre conforme à l'application développée.
> **Document complémentaire (juin 2026)** — réflexions sur le **modèle famille / numéro de dossier**, familles recomposées, tuteurs et responsables légaux : voir **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**. > **Intrant pour #117** (amendement CDC post-0.1.0). Compléter avec le [bilan 0.1.0](./29_BILAN-VERSION-0.1.0.md) et **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**.
> **Obsolète depuis #152** : ne plus proposer de champ « naissance multiple / `est_multiple` » — retiré de lapp (BDD, API, front).
## 1. Gestion des Enfants ## 1. Gestion des Enfants
@@ -11,7 +13,6 @@ Ce document liste les modifications à apporter au cahier des charges original p
#### Situation actuelle dans le CDC : #### Situation actuelle dans le CDC :
- Mentionne uniquement la collecte d'informations sur l'enfant - Mentionne uniquement la collecte d'informations sur l'enfant
- Ne précise pas la possibilité d'ajouter plusieurs enfants - Ne précise pas la possibilité d'ajouter plusieurs enfants
- Ne mentionne pas la gestion des naissances multiples
- Ne mentionne pas la gestion des enfants à naître - Ne mentionne pas la gestion des enfants à naître
#### Modifications proposées : #### Modifications proposées :
@@ -22,17 +23,18 @@ Ajouter le paragraphe suivant après la description de la collecte d'information
Les parents peuvent ajouter autant d'enfants que nécessaire. Pour chaque enfant, les informations suivantes sont collectées : Les parents peuvent ajouter autant d'enfants que nécessaire. Pour chaque enfant, les informations suivantes sont collectées :
- Prénom - Prénom
- Date de naissance (ou date prévue pour les enfants à naître) - Date de naissance (ou date prévue pour les enfants à naître)
- Genre
- Photo (optionnelle) - Photo (optionnelle)
- Consentement pour l'utilisation de la photo - Consentement pour l'utilisation de la photo
- Indication si l'enfant fait partie d'une naissance multiple (jumeaux, triplés, etc.)
Les parents peuvent : Les parents peuvent :
- Ajouter un nouvel enfant à tout moment - Ajouter un nouvel enfant à tout moment
- Supprimer un enfant ajouté - Supprimer un enfant ajouté
- Modifier les informations d'un enfant existant - Modifier les informations d'un enfant existant
- Indiquer si l'enfant est à naître - Indiquer si l'enfant est à naître
- Indiquer si l'enfant fait partie d'une naissance multiple
- Donner ou retirer leur consentement pour l'utilisation de la photo de l'enfant - Donner ou retirer leur consentement pour l'utilisation de la photo de l'enfant
Note : le concept de « naissance multiple » / jumeaux n'est pas géré par un champ dédié (retiré en 0.1.0, #152).
``` ```
### Modifications à apporter dans la section "Workflow de création de compte" ### Modifications à apporter dans la section "Workflow de création de compte"
@@ -50,9 +52,9 @@ Remplacer l'étape 3 par :
- Pour chaque enfant : - Pour chaque enfant :
* Saisie du prénom * Saisie du prénom
* Saisie de la date de naissance (ou date prévue) * Saisie de la date de naissance (ou date prévue)
* Genre
* Option d'ajout d'une photo * Option d'ajout d'une photo
* Option de consentement photo * Option de consentement photo
* Indication si naissance multiple
* Indication si enfant à naître * Indication si enfant à naître
- Possibilité de modifier ou supprimer un enfant - Possibilité de modifier ou supprimer un enfant
``` ```
+11 -7
View File
@@ -4,11 +4,15 @@ Ancienne documentation **déplacée** depuis `docs/` :
| Fichier | Motif | | Fichier | Motif |
|---------|--------| |---------|--------|
| `PROCEDURE-API-GITEA.md` | Doublon fonctionnel de | `01_CAHIER-DES-CHARGES-v1.3.md` | CDC V1.3 — remplacé par [01 V1.4](../../01_CAHIER-DES-CHARGES.md) |
[**26_GITEA-API.md**](../../26_GITEA-API.md). | | `EVOLUTIONS_CDC.md` | Patch CDC — absorbé dans V1.4 + [12_SRS](../../12_SRS-GESTION-UTILISATEURS.md) |
| `ARCHITECTURE_TECHNIQUE.md` | Non référencé ; la vue densemble est dans | `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) |
[**02_ARCHITECTURE.md**](../../02_ARCHITECTURE.md). | | `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) |
| `STATUS-APPLICATION.md` | Instantané daté ; non tenu comme doc vivante. | | `STATUS-APPLICATION.md` | Instantané daté |
| `23_LISTE-TICKETS.md` | Liste Phase 1 figée — suivi = Gitea + bilans |
| `25_PHASE-2-BACKLOG.md` | Backlog technique figé — voir [05_VERSIONS…](../../05_VERSIONS-ET-MILESTONES.md) |
| `SuperNounou_*` | CDC / SSS historiques |
| `14_NOTE-BACKEND-CONFIG-SETUP.md` | Note ticket ponctuelle |
| `92_NOTE-BACKEND-GESTIONNAIRES.md` | Note ticket ponctuelle |
Après vérification quaucun lien externe ne pointe encore vers ces chemins, on Références actives : [01 CDC V1.4](../../01_CAHIER-DES-CHARGES.md), [12 SRS users](../../12_SRS-GESTION-UTILISATEURS.md), [29 bilan 0.1.0](../../29_BILAN-VERSION-0.1.0.md).
peut **supprimer** ce sous-dossier ou ne garder que des pointeurs minimalistes.
@@ -1,127 +0,0 @@
# #131 — En-tête fiche parent : co-parent (note front → back)
**Ticket :** #131 (fiche parent dashboard, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)
**Date :** 2026-06-01
**Statut front :** livré (en-tête dynamique)
**Modif backend demandée :** **aucune fonctionnelle** — ce document fixe le contrat attendu ; le back valide `co_parent` et masque les champs sensibles.
---
## 1. Comportement UI (front)
Dans la modale **fiche parent** (`AdminParentEditModal`) :
| Zone | Contenu |
|------|---------|
| **Titre** | `prenom` + `nom` du parent affiché (plus le libellé fixe « Fiche parent ») |
| **Sous-titre** | `Co-parent : {prenom} {nom}` — affiché **uniquement** si un co-parent est connu |
Le titre se met à jour en direct pendant l’édition des champs nom/prénom.
Le sous-titre provient du co-parent **chargé depuis lAPI** (pas saisi à la main dans la modale).
---
## 2. Endpoints consommés
| Méthode | Route | Usage front |
|---------|-------|-------------|
| `GET` | `/api/v1/parents` | Liste parents (onglet Parents) |
| `GET` | `/api/v1/parents/:userId` | Rechargement fiche après rattachement/détachement enfant |
| `PATCH` | `/api/v1/parents/:userId/fiche` | Sauvegarde identité + statut (inchangé) |
Rôles : `super_admin`, `gestionnaire`, `administrateur` (selon route).
---
## 3. Contrat JSON attendu pour `co_parent`
Le front parse `ParentModel.fromJson` avec la clé **`co_parent`** (snake_case), objet utilisateur imbriqué.
### Champs minimum utilisés pour le sous-titre
| Clé JSON | Usage |
|----------|--------|
| `co_parent` | Objet ou absent/`null` |
| `co_parent.id` | Identifiant (futur lien cliquable éventuel) |
| `co_parent.prenom` | Affichage |
| `co_parent.nom` | Affichage |
Affichage front : `'{prenom} {nom}'.trim()` → libellé `Co-parent : …`.
### Exemple de fragment de réponse (`GET /parents/:id`)
```json
{
"user_id": "33333333-3333-3333-3333-333333333333",
"numero_dossier": "2026-000042",
"user": {
"id": "33333333-3333-3333-3333-333333333333",
"email": "parent1@example.com",
"prenom": "Paul",
"nom": "PARENT",
"statut": "actif",
"telephone": "0601020304"
},
"co_parent": {
"id": "44444444-4444-4444-4444-444444444444",
"email": "coparent1@example.com",
"prenom": "Clara",
"nom": "COPARENT",
"role": "parent",
"statut": "actif"
},
"parentChildren": []
}
```
> **Note :** le front lit `user` (pas `utilisateur`). La doc `11_API.md` § Parents mentionne encore `utilisateur` / `id_co_parent` seul — le contrat **effectif** côté Nest/TypeORM est lentité `Parents` sérialisée (`user`, `co_parent`, `parentChildren`, …).
---
## 4. État backend
### Relations (déjà en place)
- `findAll()` et `findOne(user_id)` chargent **`co_parent`** ;
- FK : `parents.id_co_parent``utilisateurs.id` ;
- inscription couple : les deux sens renseignés en principe (`auth.service.ts`).
### Livraison back (#131)
- `mapParentForApi` / `sanitizeUserForApi` : réponses `GET/PATCH/POST/DELETE` parents **sans** `password`, `token_creation_mdp`, `password_reset_*` sur `user` et `co_parent`.
**Checklist validation :**
- [x] `GET /parents/:id` renvoie `co_parent` peuplé quand `id_co_parent` est non null
- [x] `GET /parents` (liste) inclut `co_parent`
- [x] `prenom` / `nom` du co-parent présents
- [x] Pas de fuite `password` / tokens sur `user` ni `co_parent`
---
## 5. Points dattention (hors périmètre immédiat)
| Sujet | Détail |
|-------|--------|
| **Lien inverse** | Si B est co-parent de A (`A.id_co_parent = B`) mais `B.id_co_parent` est `null`, le sous-titre **ne saffichera pas** sur la fiche de B. Pas de résolution inverse côté front. |
| **Familles > 2 adultes** | Sous-titre = co-parent direct (`id_co_parent`) uniquement. |
| **Trou AM ↔ enfants en garde** | Pas de lien AMenfant aujourdhui (à documenter / traiter plus tard). |
---
## 6. Fichiers back concernés
| Fichier | Rôle |
|---------|------|
| `backend/src/routes/parents/parents.service.ts` | `findOne`, `findAll` + relations |
| `backend/src/routes/parents/parents.controller.ts` | `mapParentForApi` sur les réponses |
| `backend/src/routes/parents/parents.mapper.ts` | Sérialisation API |
| `backend/src/common/utils/sanitize-user-for-api.ts` | Masquage secrets |
| `backend/src/entities/parents.entity.ts` | relation `co_parent` |
---
## 7. Références
- `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1
- Ticket Gitea **#131**
@@ -1,36 +0,0 @@
# Archivé docs/archive/temporaires/ — export jetable, supprimer si inutile.
Point tickets frontend (API Gitea) - 27/01/2026
================================================
Issues avec label "frontend" : 20 (ouvertes: 12, fermees: 8)
Num | Etat | Titre
----+--------+--------------------------------------------------------
35 | open | [Frontend] Écran Création Gestionnaire
36 | closed | [Frontend] Inscription Parent - Étape 1 (Parent 1)
37 | closed | [Frontend] Inscription Parent - Étape 2 (Parent 2)
38 | closed | [Frontend] Inscription Parent - Étape 3 (Enfants)
39 | closed | [Frontend] Inscription Parent - Étapes 4-6 (Finalisatio
40 | closed | [Frontend] Inscription AM - Panneau 1 (Identité)
41 | closed | [Frontend] Inscription AM - Panneau 2 (Infos pro)
42 | closed | [Frontend] Inscription AM - Finalisation
43 | open | [Frontend] Écran Création Mot de Passe
44 | closed | [Frontend] Dashboard Gestionnaire - Structure
45 | open | [Frontend] Dashboard Gestionnaire - Liste Parents
46 | open | [Frontend] Dashboard Gestionnaire - Liste AM
47 | open | [Frontend] Écran Changement MDP Obligatoire
48 | open | [Frontend] Gestion Erreurs & Messages
49 | open | [Frontend] Écran Gestion Documents Légaux (Admin)
50 | open | [Frontend] Affichage dynamique CGU lors inscription
51 | open | [Frontend] Écran Logs Admin (optionnel v1.1)
54 | open | [Tests] Tests E2E Frontend
82 | closed | [Frontend] Adapter cran Login pour mobile
83 | closed | [Frontend] Adapter cran Choix Inscription pour mobile
Suivi doc 23_LISTE-TICKETS (Gitea #73,78,79,81,82,83):
#73 closed labels=[]
#78 closed labels=[]
#79 closed labels=[]
#81 closed labels=[]
#82 closed (écran Login mobile)
#83 closed labels=['frontend', 'p3', 'phase-1', 'ux']
+8 -7
View File
@@ -1,10 +1,11 @@
# Temporaires # Temporaires
Fichiers **non numérotés** de travail (brouillons, listes de tickets exportées, Dossier **vide** après clôture 0.1.0 (purge sept. 2026).
alignements UI en cours, etc.).
- Préfixe conseillé pour les nouveaux fichiers jetables : **`TEMP_`** ou Si un brouillon de travail est nécessaire un temps :
**`WIP_`** dans ce dossier.
- **Suppression** : dès que la fonctionnalité est livrée ou le sujet clos, - le placer ici avec préfixe `TEMP_` / `WIP_` ;
supprimer le fichier (ou le déplacer vers `obsolete/` si une trace utile - le **supprimer** dès livraison (ne pas laisser pourrir) ;
reste nécessaire). - pour une trace utile durable → bilan de version ou archive `obsolete/`.
Ne plus utiliser `docs/tmp/`.
@@ -1,244 +0,0 @@
# #112 — Alignement front après évolution back (reprise dossier complet)
**Branche déployée :** `feature/112-reprise-apres-refus-front`
**Commit back :** `d70577b1``feat(#112): reprise après refus — dossier complet GET/PATCH`
**Date :** 2026-06-16
Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de lidentité seule).
---
## 1. Endpoints (inchangés côté URL)
| Méthode | Route | Auth |
|---------|-------|------|
| `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
| `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
| `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
> **Note :** le ticket #111 parlait de `PUT` ; limplémentation reste en **`PATCH`** (comme avant).
---
## 2. `GET /auth/reprise-dossier` — réponse enrichie
### Champs communs (toujours présents)
Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
### Rôle `parent` (+ champs #119)
Alignés sur `DossierFamilleCompletDto` :
```json
{
"parents": [
{
"user_id": "uuid",
"email": "…",
"prenom": "…",
"nom": "…",
"telephone": "…",
"adresse": "…",
"ville": "…",
"code_postal": "…",
"statut": "refuse",
"co_parent_id": "uuid-parent-entity"
}
],
"enfants": [
{
"id": "uuid-enfant",
"first_name": "Emma",
"last_name": "MARTIN",
"genre": "F",
"status": "actif",
"birth_date": "2023-02-15T00:00:00.000Z",
"due_date": null,
"photo_url": "/uploads/photos/…",
"consent_photo": true,
"est_multiple": false
}
],
"texte_motivation": "Nous recherchons…"
}
```
**Mapping front suggéré :**
| JSON back | Modèle / wizard parent |
|-----------|-------------------------|
| `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
| `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
| `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
| `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
| `enfants[].status` | `actif` = né, `a_naitre` = à naître |
| `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
| `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
| `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
| `texte_motivation` | étape présentation / motivation |
Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
### Rôle `assistante_maternelle`
Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
```json
{
"consentement_photo": true,
"date_naissance": "1985-03-12T00:00:00.000Z",
"lieu_naissance_ville": "Paris",
"lieu_naissance_pays": "France",
"numero_agrement": "AGR-2024-12345",
"nir": "123456789012345",
"date_agrement": "2024-06-01T00:00:00.000Z",
"nb_max_enfants": 4,
"place_disponible": 2,
"biographie": "…"
}
```
**Mapping `AmRegistrationData` :**
| JSON back | Champ front |
|-----------|-------------|
| `nb_max_enfants` | `capaciteAccueil` |
| `place_disponible` | `placesDisponibles` |
| `numero_agrement` | `numeroAgrement` |
| `biographie` | `biographie` / présentation |
| `photo_url` | déjà géré via `RepriseSession.photoUrl` |
---
## 3. `PATCH /auth/reprise-resoumettre` — body étendu
### Commun
```json
{ "token": "uuid-reprise" }
```
### Parent — champs à envoyer depuis le wizard
| Champ PATCH | Source wizard | Notes |
|-------------|---------------|-------|
| `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
| `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
| `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
| `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
| `enfants[]` | Liste enfants | Voir ci-dessous |
**Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
```json
{
"id": "uuid-enfant-existant",
"prenom": "Emma",
"nom": "MARTIN",
"date_naissance": "2023-02-15",
"date_previsionnelle_naissance": null,
"genre": "F",
"photo_base64": "data:image/jpeg;base64,…",
"photo_filename": "emma.jpg",
"grossesse_multiple": false
}
```
- **v1 back :** update par `id` uniquement — pas de création/suppression denfant.
- Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
- Sans nouvelle photo : ne pas envoyer `photo_base64` (lexistant est conservé).
### AM — champs à envoyer
| Champ PATCH | Source |
|-------------|--------|
| Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 12 |
| `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
| `numero_agrement`, `nir`, `date_agrement` | Pro |
| `capacite_accueil`, `places_disponibles` | Pro |
| `biographie` | Présentation |
Validation NIR identique à linscription si `nir` fourni.
### Réponse succès (nouveau format)
```json
{
"message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
"statut": "en_attente",
"user_id": "uuid",
"numero_dossier": "2026-000021"
}
```
Code HTTP : **200** (pas de corps `Users` brut comme lancien back).
### Effet métier
- **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
- **AM :** un seul user.
### E-mail accusé resoumission (parent)
Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
- confirmation de resoumission ;
- rappel du **numéro de dossier** ;
- mention « en attente de validation ».
Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
---
## 4. Fichiers front à modifier (checklist)
### Modèles
- [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
- [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
### Session / préremplissage
- [ ] `lib/services/reprise_session.dart`
- `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
- `applyToAm` : remplir tous les champs AM
### API
- [ ] `lib/services/auth_service.dart``resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
- [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
### Écrans fin de parcours
- [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
- [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
### Hors scope back (inchangé)
RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
### Non implémenté front (ticket #112 initial)
- [ ] Modale login « Jai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
---
## 5. Tests manuels suggérés
1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
2. Ouvrir le lien mail `/reprise?token=…`.
3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
4. Après branchement front : wizard prérempli sur toutes les étapes.
5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
---
## 6. Références code back
```
backend/src/routes/auth/dto/reprise-dossier.dto.ts
backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
backend/src/routes/auth/dto/enfant-reprise.dto.ts
backend/src/routes/auth/auth.service.ts → getRepriseDossier, resoumettreReprise
backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
```
@@ -1,132 +0,0 @@
# #131 — Fiche AM éditable + affiliation enfants (note front → back)
**Ticket :** #131 (partie AM, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)
**Date :** 2026-06-01
**Statut front :** modale livrée (2 onglets) — **API affiliation AM↔enfant à implémenter**
---
## 1. Comportement UI (front)
Modale `AdminAmEditModal` — même shell que la fiche parent (~930 px) :
| Onglet | Contenu |
|--------|---------|
| **Identité & professionnel** | `IdentityBlock` éditable + grille pro (agrément, ville résidence, capacité, places, NIR/agrément date en lecture seule, biographie, switch disponible) + gélule statut |
| **Enfants accueillis** | Liste cartes enfants (réutilise `AdminChildrenAffiliationPanel` / `AdminEnfantUserCard`) + rattacher / détacher |
En-tête : prénom nom · sous-titre `Zone · Agrément · Dossier`.
---
## 2. Endpoints consommés
### Déjà existants (partiels)
| Méthode | Route | Usage |
|---------|-------|-------|
| `GET` | `/api/v1/assistantes-maternelles` | Liste AM |
| `GET` | `/api/v1/assistantes-maternelles/:userId` | Détail (403 possible pour `administrateur` → fallback liste) |
| `PATCH` | `/api/v1/users/:userId` | Identité + statut (admin / super_admin uniquement) |
| `PATCH` | `/api/v1/assistantes-maternelles/:userId` | Champs pro (gestionnaire / super_admin) |
### À créer (recommandé — miroir parent #131 / #115)
| Méthode | Route | Rôle |
|---------|-------|------|
| `PATCH` | `/api/v1/assistantes-maternelles/:userId/fiche` | Mise à jour unifiée identité + pro + statut (`super_admin`, `gestionnaire`, `administrateur`) |
| `POST` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Rattacher un enfant |
| `DELETE` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Détacher un enfant |
| `GET` | `/api/v1/assistantes-maternelles/:userId` | Inclure `amChildren[]` (relation enfant) |
Le front appelle déjà ces routes ; en labsence de `PATCH …/fiche`, il tente un fallback `PATCH users` + `PATCH assistantes-maternelles` (échoue selon le rôle connecté).
---
## 3. Modèle de données affiliation AM ↔ enfant
**À définir côté BDD** (pas de table dédiée aujourdhui, contrairement à `enfants_parents`) :
Proposition alignée parent :
```sql
-- Piste : enfants_assistantes_maternelles
CREATE TABLE enfants_assistantes_maternelles (
id_am UUID NOT NULL REFERENCES utilisateurs(id) ON DELETE CASCADE,
id_enfant UUID NOT NULL REFERENCES enfants(id) ON DELETE CASCADE,
PRIMARY KEY (id_am, id_enfant)
);
```
Réponse API attendue sur `GET /assistantes-maternelles/:id` :
```json
{
"user_id": "uuid-am",
"user": { "id": "…", "prenom": "Claire", "nom": "MARTIN", "statut": "actif" },
"approval_number": "AGR-2024-12345",
"residence_city": "Bezons",
"max_children": 4,
"places_available": 2,
"available": true,
"amChildren": [
{
"child": {
"id": "uuid-enfant",
"first_name": "Emma",
"last_name": "MARTIN",
"status": "actif",
"birth_date": "2023-02-15"
}
}
]
}
```
Le front parse `amChildren` / `am_children` / `assistanteChildren` (même logique que `parentChildren`).
---
## 4. Body `PATCH …/fiche` suggéré
```json
{
"nom": "MARTIN",
"prenom": "Claire",
"email": "claire@example.com",
"telephone": "0612345678",
"adresse": "5 place Bellecour",
"ville": "Lyon",
"code_postal": "69002",
"statut": "actif",
"approval_number": "AGR-2024-12345",
"residence_city": "Lyon",
"max_children": 4,
"places_available": 2,
"biography": "…",
"available": true
}
```
NIR et date dagrément : lecture seule dans la modale (modification hors périmètre admin v1).
---
## 5. Fichiers front concernés
| Fichier | Rôle |
|---------|------|
| `frontend/lib/widgets/admin/common/admin_am_edit_modal.dart` | Modale 2 onglets |
| `frontend/lib/widgets/admin/common/admin_children_affiliation_panel.dart` | Liste enfants partagée parent/AM |
| `frontend/lib/widgets/admin/common/admin_status_capsule.dart` | Gélule statut partagée |
| `frontend/lib/models/assistante_maternelle_model.dart` | Parse champs pro + `amChildren` |
| `frontend/lib/services/user_service.dart` | `getAssistanteMaternelle`, `updateAmFiche`, `attachEnfantToAm`, `detachEnfantFromAm` |
| `frontend/lib/widgets/admin/assistante_maternelle_management_widget.dart` | Ouverture modale au clic Modifier |
---
## 6. Références
- Fiche parent : `PATCH /parents/:id/fiche`, `POST|DELETE /parents/:id/enfants/:enfantId`
- Ticket Gitea **#131**, **#115**
- `docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md`
@@ -1,124 +0,0 @@
# #131 — En-tête fiche parent : co-parent (note front → back)
**Ticket :** #131 (fiche parent dashboard, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)
**Date :** 2026-06-01
**Statut front :** livré (en-tête dynamique)
**Modif backend demandée :** **aucune** — ce document fixe le contrat attendu et invite à valider que lexistant le couvre.
---
## 1. Comportement UI (front)
Dans la modale **fiche parent** (`AdminParentEditModal`) :
| Zone | Contenu |
|------|---------|
| **Titre** | `prenom` + `nom` du parent affiché (plus le libellé fixe « Fiche parent ») |
| **Sous-titre** | `Co-parent : {prenom} {nom}` — affiché **uniquement** si un co-parent est connu |
Le titre se met à jour en direct pendant l’édition des champs nom/prénom.
Le sous-titre provient du co-parent **chargé depuis lAPI** (pas saisi à la main dans la modale).
---
## 2. Endpoints consommés
| Méthode | Route | Usage front |
|---------|-------|-------------|
| `GET` | `/api/v1/parents` | Liste parents (onglet Parents) |
| `GET` | `/api/v1/parents/:userId` | Rechargement fiche après rattachement/détachement enfant |
| `PATCH` | `/api/v1/parents/:userId/fiche` | Sauvegarde identité + statut (inchangé) |
Rôles : `super_admin`, `gestionnaire`, `administrateur` (selon route).
---
## 3. Contrat JSON attendu pour `co_parent`
Le front parse `ParentModel.fromJson` avec la clé **`co_parent`** (snake_case), objet utilisateur imbriqué.
### Champs minimum utilisés pour le sous-titre
| Clé JSON | Usage |
|----------|--------|
| `co_parent` | Objet ou absent/`null` |
| `co_parent.id` | Identifiant (futur lien cliquable éventuel) |
| `co_parent.prenom` | Affichage |
| `co_parent.nom` | Affichage |
Affichage front : `'{prenom} {nom}'.trim()` → libellé `Co-parent : …`.
### Exemple de fragment de réponse (`GET /parents/:id`)
```json
{
"user_id": "33333333-3333-3333-3333-333333333333",
"numero_dossier": "2026-000042",
"user": {
"id": "33333333-3333-3333-3333-333333333333",
"email": "parent1@example.com",
"prenom": "Paul",
"nom": "PARENT",
"statut": "actif",
"telephone": "0601020304"
},
"co_parent": {
"id": "44444444-4444-4444-4444-444444444444",
"email": "coparent1@example.com",
"prenom": "Clara",
"nom": "COPARENT",
"role": "parent",
"statut": "actif"
},
"parentChildren": []
}
```
> **Note :** le front lit `user` (pas `utilisateur`). La doc `11_API.md` § Parents mentionne encore `utilisateur` / `id_co_parent` seul — le contrat **effectif** côté Nest/TypeORM est lentité `Parents` sérialisée (`user`, `co_parent`, `parentChildren`, …).
---
## 4. État backend (à valider, pas à refaire)
Daprès le code actuel (`parents.service.ts`) :
- `findAll()` et `findOne(user_id)` chargent déjà la relation **`co_parent`** ;
- la FK métier est `parents.id_co_parent``utilisateurs.id` ;
- à linscription couple, les deux sens sont en principe renseignés (`auth.service.ts`).
**Checklist validation back :**
- [ ] `GET /parents/:id` renvoie bien `co_parent` peuplé quand `id_co_parent` est non null
- [ ] `GET /parents` (liste) inclut aussi `co_parent` (sous-titre disponible dès louverture sans re-fetch)
- [ ] Les champs `prenom` / `nom` du co-parent sont présents dans la réponse JSON
Si ces trois points passent en recette, **aucun changement backend nest nécessaire** pour cette fonctionnalité.
---
## 5. Points dattention (hors périmètre immédiat)
| Sujet | Détail |
|-------|--------|
| **Lien inverse** | Si le parent B est le co-parent de A (`A.id_co_parent = B`) mais que `B.id_co_parent` est `null`, le sous-titre **ne saffichera pas** sur la fiche de B. Le front ne fait pas de résolution inverse. À traiter côté back **seulement si** des données legacy ont un lien à sens unique. |
| **Familles > 2 adultes** | Le sous-titre naffiche que le co-parent direct (`id_co_parent`). Les autres responsables liés uniquement via `enfants_parents` ne sont pas listés ici (cf. doc 28 §6). |
| **Données sensibles** | Vérifier que la sérialisation de `co_parent` nexpose pas `password` / tokens (même remarque que pour `user`). |
---
## 6. Fichiers front concernés
| Fichier | Rôle |
|---------|------|
| `frontend/lib/models/parent_model.dart` | Parse `co_parent``AppUser? coParent` |
| `frontend/lib/widgets/admin/common/admin_parent_edit_modal.dart` | Titre + sous-titre |
| `frontend/lib/services/user_service.dart` | `getParents()` / `getParent()` |
---
## 7. Références
- `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1
- `backend/src/routes/parents/parents.service.ts``findOne`, `findAll`
- `backend/src/entities/parents.entity.ts` — relation `co_parent`
- Ticket Gitea **#131**
@@ -1,46 +0,0 @@
# TEMP — Alignement front / API (inscription AM & validation gestionnaire)
> **Archivé** (`docs/archive/temporaires/`) — **fichier temporaire** ; à
> **supprimer** une fois le front livré ou le sujet clos (voir
> `docs/archive/temporaires/README.md`).
Ce document décrit les changements **côté API** et ce que **Flutter** doit faire pour rester aligné. Aucune modification front na été faite dans le chantier backend associé.
## 1. `POST /auth/register/am` — lieu de naissance obligatoire
- **`lieu_naissance_ville`** et **`lieu_naissance_pays`** sont **obligatoires** (non vides après trim, min. **2 caractères** chacun, max 100).
- Réponses **400** si manquants ou invalides (messages class-validator).
- **Action front** : champs obligatoires dans le parcours AM (étapes identité / naissance), validation UI avant envoi ; afficher les erreurs renvoyées par lAPI.
## 2. Réponse `GET /dossiers/:numeroDossier` (type `am`)
Sous `dossier.user`, lAPI peut inclure :
| Clé JSON | Description |
|----------|-------------|
| `date_naissance` | Date (si renseignée à linscription) |
| `lieu_naissance_ville` | Ville de naissance |
| `lieu_naissance_pays` | Pays de naissance |
| `consentement_photo` | Booléen (exposé dans `dossier.user`) |
À la **racine** de `dossier` (objet AM), champs déjà renvoyés par le backend : `disponible`, `annees_experience`, `specialite`, `nb_max_enfants`, `place_disponible`, etc.
**Action front** :
- Étendre **`AppUser.fromJson` / `toJson`** (`lib/models/user.dart`) pour mapper `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays`, `consentement_photo`.
- Étendre **`DossierAM.fromJson`** (`lib/models/dossier_unifie.dart`) pour parser `disponible`, `annees_experience`, `specialite` à la racine du dossier (noms snake_case comme dans la réponse JSON Nest).
## 3. `ValidationAmWizard` (admin)
Afficher pour cohérence avec le formulaire dinscription :
- **Informations personnelles** : date de naissance, ville / pays de naissance, consentement photo (Oui/Non).
- **Informations professionnelles** : disponibilité, années dexpérience, spécialité (afficher « » si `null`).
## 4. `place_disponible` à linscription
- Le backend initialise **`place_disponible`** sur la fiche AM à la **même valeur** que **`capacite_accueil`** à la création. Le wizard peut donc afficher une valeur cohérente avec la capacité sans champ séparé côté public.
---
*Dernière mise à jour : alignement backend branche `feature/120-inscription-am-photo-backend`.*
+29
View File
@@ -0,0 +1,29 @@
# Maquettes — espaces parent / AM (quotidien)
Références visuelles issues de latelier de cadrage (sept. 2026).
## Organisation
| Dossier | Contenu |
|---------|---------|
| [`courantes/`](./courantes/) | **Référence active** — à utiliser pour tickets / implémentation |
| [`historique/`](./historique/) | Itérations précédentes + croquis manuscrit (conservées pour traçabilité) |
## Référence active
| Fichier | Description |
|---------|-------------|
| [`courantes/maquette-dashboard-parent-quotidien-v4.png`](./courantes/maquette-dashboard-parent-quotidien-v4.png) | TdB parent PC — **3 colonnes** : cartes + couple · blog (défaut) · messagerie (AM / RPE) |
## Historique
| Fichier | Note |
|---------|------|
| [`historique/croquis-dashboard-parent-2026-09-23.jpg`](./historique/croquis-dashboard-parent-2026-09-23.jpg) | Wireframe manuscrit (WhatsApp) — point de départ layout |
| `…-v1.png` | Première génération IA (~50/50) |
| `…-v2.png` | Recadrage 1/3 + 2/3 (onglets Mess/Blog à droite) |
| `…-v3.png` | Couple enfantnounou (encore 2 colonnes) |
## Suite éventuelle
- Maquette **TdB AM** (miroir : bandeau enfant \| parent(s)) — pas encore générée.
Binary file not shown.

After

Width:  |  Height:  |  Size: 185 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 149 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 149 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 178 KiB

@@ -1,244 +0,0 @@
# #112 — Alignement front après évolution back (reprise dossier complet)
**Branche déployée :** `feature/112-reprise-apres-refus-front`
**Commit back :** `d70577b1``feat(#112): reprise après refus — dossier complet GET/PATCH`
**Date :** 2026-06-16
Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de lidentité seule).
---
## 1. Endpoints (inchangés côté URL)
| Méthode | Route | Auth |
|---------|-------|------|
| `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
| `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
| `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
> **Note :** le ticket #111 parlait de `PUT` ; limplémentation reste en **`PATCH`** (comme avant).
---
## 2. `GET /auth/reprise-dossier` — réponse enrichie
### Champs communs (toujours présents)
Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
### Rôle `parent` (+ champs #119)
Alignés sur `DossierFamilleCompletDto` :
```json
{
"parents": [
{
"user_id": "uuid",
"email": "…",
"prenom": "…",
"nom": "…",
"telephone": "…",
"adresse": "…",
"ville": "…",
"code_postal": "…",
"statut": "refuse",
"co_parent_id": "uuid-parent-entity"
}
],
"enfants": [
{
"id": "uuid-enfant",
"first_name": "Emma",
"last_name": "MARTIN",
"genre": "F",
"status": "actif",
"birth_date": "2023-02-15T00:00:00.000Z",
"due_date": null,
"photo_url": "/uploads/photos/…",
"consent_photo": true,
"est_multiple": false
}
],
"texte_motivation": "Nous recherchons…"
}
```
**Mapping front suggéré :**
| JSON back | Modèle / wizard parent |
|-----------|-------------------------|
| `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
| `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
| `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
| `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
| `enfants[].status` | `actif` = né, `a_naitre` = à naître |
| `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
| `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
| `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
| `texte_motivation` | étape présentation / motivation |
Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
### Rôle `assistante_maternelle`
Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
```json
{
"consentement_photo": true,
"date_naissance": "1985-03-12T00:00:00.000Z",
"lieu_naissance_ville": "Paris",
"lieu_naissance_pays": "France",
"numero_agrement": "AGR-2024-12345",
"nir": "123456789012345",
"date_agrement": "2024-06-01T00:00:00.000Z",
"nb_max_enfants": 4,
"place_disponible": 2,
"biographie": "…"
}
```
**Mapping `AmRegistrationData` :**
| JSON back | Champ front |
|-----------|-------------|
| `nb_max_enfants` | `capaciteAccueil` |
| `place_disponible` | `placesDisponibles` |
| `numero_agrement` | `numeroAgrement` |
| `biographie` | `biographie` / présentation |
| `photo_url` | déjà géré via `RepriseSession.photoUrl` |
---
## 3. `PATCH /auth/reprise-resoumettre` — body étendu
### Commun
```json
{ "token": "uuid-reprise" }
```
### Parent — champs à envoyer depuis le wizard
| Champ PATCH | Source wizard | Notes |
|-------------|---------------|-------|
| `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
| `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
| `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
| `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
| `enfants[]` | Liste enfants | Voir ci-dessous |
**Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
```json
{
"id": "uuid-enfant-existant",
"prenom": "Emma",
"nom": "MARTIN",
"date_naissance": "2023-02-15",
"date_previsionnelle_naissance": null,
"genre": "F",
"photo_base64": "data:image/jpeg;base64,…",
"photo_filename": "emma.jpg",
"grossesse_multiple": false
}
```
- **v1 back :** update par `id` uniquement — pas de création/suppression denfant.
- Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
- Sans nouvelle photo : ne pas envoyer `photo_base64` (lexistant est conservé).
### AM — champs à envoyer
| Champ PATCH | Source |
|-------------|--------|
| Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 12 |
| `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
| `numero_agrement`, `nir`, `date_agrement` | Pro |
| `capacite_accueil`, `places_disponibles` | Pro |
| `biographie` | Présentation |
Validation NIR identique à linscription si `nir` fourni.
### Réponse succès (nouveau format)
```json
{
"message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
"statut": "en_attente",
"user_id": "uuid",
"numero_dossier": "2026-000021"
}
```
Code HTTP : **200** (pas de corps `Users` brut comme lancien back).
### Effet métier
- **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
- **AM :** un seul user.
### E-mail accusé resoumission (parent)
Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
- confirmation de resoumission ;
- rappel du **numéro de dossier** ;
- mention « en attente de validation ».
Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
---
## 4. Fichiers front à modifier (checklist)
### Modèles
- [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
- [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
### Session / préremplissage
- [ ] `lib/services/reprise_session.dart`
- `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
- `applyToAm` : remplir tous les champs AM
### API
- [ ] `lib/services/auth_service.dart``resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
- [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
### Écrans fin de parcours
- [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
- [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
### Hors scope back (inchangé)
RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
### Non implémenté front (ticket #112 initial)
- [ ] Modale login « Jai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
---
## 5. Tests manuels suggérés
1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
2. Ouvrir le lien mail `/reprise?token=…`.
3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
4. Après branchement front : wizard prérempli sur toutes les étapes.
5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
---
## 6. Références code back
```
backend/src/routes/auth/dto/reprise-dossier.dto.ts
backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
backend/src/routes/auth/dto/enfant-reprise.dto.ts
backend/src/routes/auth/auth.service.ts → getRepriseDossier, resoumettreReprise
backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
```
-89
View File
@@ -1,89 +0,0 @@
# Mini-spec API — POST /parents/dossier (#129)
Contrat pour le **plan front** (wizard création dossier famille staff).
Miroir de **#156** (`POST /assistantes-maternelles/dossier`).
## Endpoint
| | |
|--|--|
| **Méthode** | `POST` |
| **URL** | `{base}/parents/dossier` |
| **Auth** | Bearer JWT |
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
| **Content-Type** | `application/json` |
Ne **pas** appeler `POST /auth/register/parent` depuis le dashboard.
## Body (JSON)
Aligné `RegisterParentCompletDto`, **sans** CGU/privacy obligatoires (acceptées serveur).
### Parent 1 (obligatoire)
| Champ | Type | Obligatoire | Notes |
|-------|------|-------------|--------|
| `email` | string | oui | unique |
| `prenom` | string | oui | |
| `nom` | string | oui | |
| `telephone` | string | oui | `0X…` ou `+33…` |
| `adresse` | string | non | |
| `code_postal` | string | non | |
| `ville` | string | non | |
### Co-parent (optionnel)
`co_parent_email`, `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone`,
`co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville`.
Si co-parent fourni : e-mail distinct ; mêmes règles téléphone / adresse que register.
### Enfants (≥ 1)
| Champ | Type | Notes |
|-------|------|--------|
| `enfants` | `EnfantInscriptionDto[]` | `prenom`, `nom`, `date_naissance` / `date_previsionnelle_naissance`, `genre`, `photo_base64`, `photo_filename`, etc. |
### Présentation
| Champ | Type | Obligatoire |
|-------|------|-------------|
| `presentation_dossier` | string | non (max 2000) |
## Réponses
### 201 Created
```json
{
"message": "Dossier famille créé et validé. Un e-mail de création de mot de passe a été envoyé.",
"numero_dossier": "2026-000043",
"parent_user_id": "uuid-pivot",
"co_parent_user_id": "uuid-ou-null",
"statut": "actif",
"enfant_ids": ["uuid", "..."]
}
```
Effets serveur : user(s) parent **actif**, fiches `parents`, enfants + foyer, n° dossier,
**e-mail création MDP** pour chaque compte sans MDP (pas daccusé « en attente »).
### Erreurs
| Code | Cas |
|------|-----|
| 400 | Validation DTO / métier (enfants vides, dates, etc.) |
| 401 | Token manquant / invalide |
| 403 | Rôle non staff |
| 409 | Conflit e-mail (pivot et/ou co-parent) |
## Front
- `UserService.createParentDossier(body)` → cet endpoint
- Wizard create basé sur `ValidationFamilyWizard`
- Ne pas envoyer `acceptation_cgu` / `acceptation_privacy` (optionnels)
## Branche
`feature/129-creation-dossier-parent`
@@ -1,73 +0,0 @@
# Mini-spec API — POST /parents/:id/co-parent (#135)
Contrat back pour lajout dun **2ᵉ parent** sur un foyer mono-parent (staff).
## Endpoint
| | |
|--|--|
| **Méthode** | `POST` |
| **URL** | `{base}/api/v1/parents/{parentUserId}/co-parent` |
| **Auth** | Bearer JWT |
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
| **Succès** | **201** |
`parentUserId` = UUID du **parent pivot** (déjà dans le dossier).
Ne **pas** appeler `POST /auth/register/parent` ni `POST /parents/dossier`.
---
## Body (JSON)
| Champ | Type | Obligatoire | Notes |
|-------|------|-------------|--------|
| `email` | string | oui | unique |
| `prenom` | string | oui | |
| `nom` | string | oui | |
| `telephone` | string | oui | `0X…` ou `+33…` |
| `meme_adresse` | bool | non | défaut **true** → copie adresse du pivot |
| `adresse` | string | si `meme_adresse=false` | |
| `code_postal` | string | si `meme_adresse=false` | |
| `ville` | string | si `meme_adresse=false` | |
---
## Comportement 201
- User co-parent **actif** + token création MDP
- Fiche `parents` + liens pivot ↔ co-parent + même `numero_dossier`
- Enfants du foyer rattachés au co-parent
- E-mail **création MDP** (pas mail « en attente »)
```json
{
"message": "Co-parent ajouté au foyer. Un e-mail de création de mot de passe a été envoyé.",
"numero_dossier": "2026-000043",
"parent_user_id": "uuid-pivot",
"co_parent_user_id": "uuid-co",
"statut": "actif"
}
```
## Erreurs
| Code | Cas |
|------|-----|
| 400 | Déjà un co-parent / 2 responsables / validation adresse |
| 401 | Token invalide |
| 403 | Rôle non staff |
| 404 | Pivot introuvable |
| 409 | Email déjà pris |
## Réemploi édition identité
| Endpoint | Usage |
|----------|--------|
| `GET /dossiers/:numero` | Préremplir wizard edit |
| `PATCH /parents/:id/fiche` | Sauver identité pivot / co-parent existant |
| `PATCH /assistantes-maternelles/:id/fiche` | Édition AM |
## Branche
`feature/135-edition-dossier`
@@ -1,83 +0,0 @@
# Mini-spec front — Mode édition dossier + ajout 2ᵉ parent (#135)
Branche : `feature/135-edition-dossier`
Ticket : **#135** (full-stack)
Prérequis : **#153** (liste Dossiers) livré.
---
## Objectif
1. Clic sur un dossier (liste #153) → ouvrir le wizard en mode **`edit`**
2. Foyer **mono-parent** : page co-parent → **switch** ajouter un 2ᵉ parent
3. Sauvegarder les champs via APIs existantes + nouvel endpoint co-parent
---
## Modes wizard
| Mode | Famille | AM |
|------|---------|-----|
| `review` | déjà | déjà |
| `create` | déjà (#129) | déjà (#156) |
| **`edit`** | **à faire** | **à faire** |
Factories : `ParentDossierWizard.edit(...)` / `AmDossierWizard.edit(...)`
Préremplir via `UserService.getDossierByNumero(numero)`.
---
## APIs
| Action | Endpoint |
|--------|----------|
| Charger | `GET /dossiers/:numero` |
| Sauver parent | `PATCH /parents/:id/fiche` |
| Sauver AM | `PATCH /assistantes-maternelles/:id/fiche` |
| **Ajouter co-parent** | **`POST /parents/:pivotUserId/co-parent`** — voir `docs/tmp/135-contrat-api-ajout-co-parent.md` |
Body co-parent :
```json
{
"email": "thomas@…",
"prenom": "Thomas",
"nom": "MARTIN",
"telephone": "0678456789",
"meme_adresse": true
}
```
`UserService.addCoParent(pivotUserId, body)` → cet endpoint.
---
## UX
- Depuis `DossiersManagementWidget` / carte liste : clic → edit (plus seulement review pending)
- Pending : garder validation (review) ; dossiers actifs → edit
- Mono-parent : switch « Ajouter un co-parent » (comme create) → au save, `POST …/co-parent` si nouveau
- Déjà 2 parents : éditer les deux fiches ; pas de 3ᵉ
- Pas de bouton créer dans longlet Dossiers
---
## Hors scope
- Famille N responsables (#139)
- Suppressions (#154)
- Création dossier initial (#129 / #156)
---
## Critères dacceptation
- [ ] Clic dossier actif → wizard edit prérempli
- [ ] PATCH fiche enregistre les modifs
- [ ] Mono-parent + switch → co-parent créé (actif + mail MDP)
- [ ] review / create inchangés
## Branche
`feature/135-edition-dossier`
@@ -1,65 +0,0 @@
# Mini-spec — Suppression complète grossesse multiple / `est_multiple`
**Ticket** : **#152** — https://git.ptits-pas.fr/jmartin/petitspas/issues/152
**Branche** : `feature/152-remove-est-multiple` (depuis `develop`)
**Périmètre** : **full stack** — BDD + back + front + scripts + docs. **Aucun fantôme.**
---
## Décision
On **supprime tout**. Pas de DTO « ignorés », pas de compat payload.
`forbidNonWhitelisted: true` ⇒ back et front **partent ensemble** (même feature / même déploiement).
---
## Alias retirés
`est_multiple` · `is_multiple` · `grossesse_multiple` · `multipleBirth` · `estMultiple` · `isMultiple` · `jumeau_multiple`
---
## Back / BDD (fait sur la branche)
- [x] Migration `database/migrations/2026_drop_enfants_est_multiple.sql`
- [x] `BDD.sql`, seeds, CSV test
- [x] Entity `Children` sans colonne
- [x] DTO create/inscription/réponse/dossier famille **sans** le champ
- [x] Services auth / enfants / parents : plus de mapping
- [x] Prisma legacy `isMultiple` retiré
## Front (fait sur la branche)
- [x] Modèles admin / dossier / inscription
- [x] Payloads inscription + reprise
- [x] Modale enfant + wizard dossier famille
- [x] Step3 inscription parent
## Scripts / docs
- [x] `tests/scripts/register-parent-*.mjs`
- [x] `docs/10_DATABASE.md`, `docs/99_REGLES-CODAGE.md`
- Docs tmp/archive #112 : mentions historiques OK (archive)
---
## Déploiement
1. Appliquer la migration SQL sur la BDD vivante
2. Deploy back **et** front de cette branche
3. Smoke : création enfant staff, inscription parent, reprise, wizard famille
## Vérif
```bash
rg -n 'est_multiple|is_multiple|grossesse_multiple|multipleBirth|estMultiple|isMultiple|jumeau_multiple' \
backend/src frontend/lib database tests/scripts docs/10_DATABASE.md docs/99_REGLES-CODAGE.md
```
**0** hit (hors ce fichier mini-spec / archives).
## Hors scope
- Métier futur « fratrie / jumeaux » → nouveau ticket
- #155 rename Admin*
- Ticket modales staff
@@ -1,77 +0,0 @@
# Mini-spec API — GET /dossiers (#153)
Contrat pour le **plan front** (onglet permanent Dossiers).
## Endpoint
| | |
|--|--|
| **Méthode** | `GET` |
| **URL** | `{base}/api/v1/dossiers` |
| **Auth** | Bearer JWT |
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
| **Query** | `q` (optionnel) — recherche n° / libellé / email |
Complète `GET /dossiers/:numeroDossier` (#119) déjà existant.
---
## Réponse 200
Tableau de lignes (1 entrée = 1 `numero_dossier`) :
```json
[
{
"type": "famille",
"numero_dossier": "2026-000043",
"libelle": "Claire MARTIN & Thomas MARTIN",
"emails": ["claire@test.fr", "thomas@test.fr"],
"user_ids": ["uuid-pivot", "uuid-co"],
"statut": "actif",
"a_valider": false,
"date_reference": "2026-01-12T10:00:00.000Z"
},
{
"type": "assistante_maternelle",
"numero_dossier": "2026-000042",
"libelle": "Marie DUPONT",
"emails": ["marie@test.fr"],
"user_ids": ["uuid-am"],
"statut": "en_attente",
"a_valider": true,
"date_reference": "2026-02-01T08:00:00.000Z"
}
]
```
### Champs
| Champ | Notes |
|-------|--------|
| `type` | `famille` \| `assistante_maternelle` |
| `numero_dossier` | Clé dunité |
| `libelle` | Noms formatés (foyer : `A & B`) |
| `emails` / `user_ids` | Membres du foyer ou AM |
| `statut` | Agrégé : `en_attente` si au moins un user pending |
| `a_valider` | `true` si pending → section haute UI |
| `date_reference` | `MIN(cree_le)` des users |
**Tri** : `a_valider` dabord, puis `numero_dossier` décroissant.
**Famille** : dédupliquée par `numero_dossier` (pivot + co-parent = 1 ligne).
---
## Front
- `UserService.getDossiers({ q? })` → cet endpoint
- Section haute : filtrer `a_valider == true` **ou** continuer pending APIs existantes
- Section basse : liste complète (ou hors pending selon règle UX)
- Clic → `GET /dossiers/:numero` (détail) / validation review
Composition client `getParents`+`getAM` **plus nécessaire** si cet endpoint est déployé.
## Branche
`feature/153-onglet-dossiers`
-167
View File
@@ -1,167 +0,0 @@
# Mini-spec front — Onglet permanent « Dossiers » (#153)
Branche Git (front + back) : `feature/153-onglet-dossiers`
Ticket Gitea : **#153** (ticket normal, plus epic)
> Suite prévue : **#135** = au clic, mode **édition** wizard + ajout 2ᵉ parent.
> **#153** = onglet + listes + navigation / validation pending. **Pas** de création, **pas** d’édition complète.
---
## Contexte / objectif
Remplacer longlet conditionnel **« À valider »** (apparaît/disparaît selon pending) par un onglet **permanent « Dossiers »** dans le dashboard admin/gestionnaire.
Quand on ouvre **Dossiers** :
1. **En haut** — section **Dossiers à valider** (AM + familles pending)
2. **En dessous** — liste de **tous les dossiers** (familles **et** AM), 1 ligne = 1 `numero_dossier`
3. Différenciation visuelle famille vs AM : **couleur + icône**
4. **Barre de recherche** (n° dossier, nom, email…)
**Pas** de bouton « Créer un dossier » ici (création via **+ Parents** #129 / **+ Asmat** #156).
---
## UX cible
### Onglets dashboard (`UserManagementPanel`)
| Avant (#107) | Après (#153) |
|--------------|--------------|
| « À valider » **conditionnel** si pending | **« Dossiers » toujours visible** (admin + gestionnaire) |
| Contenu = seulement pending | Pending **en haut** + liste complète **en bas** |
Ordre suggéré des onglets :
`Dossiers` | `Parents` | `Enfants` | `Assistantes maternelles` | `Gestionnaires` | (`Administrateurs`)
### Section haute — À valider
- Réutiliser / adapter `PendingValidationWidget` (ou extraire la liste dans un sous-widget).
- Sources déjà branchées :
- `UserService.getPendingUsers(role: 'assistante_maternelle')`
- `UserService.getPendingFamilies()`
- Clic ligne pending → **`ValidationDossierModal`** / wizards `.review` (inchangé).
- Si section vide : ne pas afficher de gros vide ; masquer la section ou message court « Aucun dossier en attente ».
### Section basse — Tous les dossiers
1 ligne = **1 dossier** (`numero_dossier`), type :
| Type | Libellé UI | Couleur (suggestion) |
|------|------------|----------------------|
| `famille` | Famille / Parents | teinte existante parents (ex. violet / rose dashboard) |
| `assistante_maternelle` | AM | teinte existante AM (ex. teal / bleu) |
Colonnes / infos utiles (cartes style `AdminUserCard` ou lignes type pending) :
- n° dossier
- type (pastille couleur + icône)
- libellé (noms parents ou AM)
- email(s) principal(aux)
- statut user / dossier si dispo (`actif`, `en_attente`, …)
- date utile si dispo
**Déduplication** : un foyer (pivot + co-parent) = **une** ligne famille (même `numero_dossier`). Idem AM.
### Recherche
- La search bar du panel (aujourdhui désactivée / hint « pas de recherche » sur À valider) doit **filtrer la liste unifiée** (et idéalement aussi le pending affiché).
- Critères **minimum** : `numero_dossier`, nom, prénom, email.
- Harmoniser le hint : `Rechercher un dossier (n°, nom, email)…`
### État vide liste complète
Aide optionnelle : *« Pour créer un dossier → onglet Parents (+ Parents) ou Assistantes maternelles (+ Asmat) »*.
### Clic sur un dossier de la liste complète (#153)
| Cas | Comportement #153 |
|-----|-------------------|
| Pending | Ouvrir validation (review) — déjà en place |
| Dossier **actif** / non pending | Ouvrir consultation via `GET /dossiers/:numeroDossier` (`UserService.getDossierByNumero`) en **lecture / review** si possible **sans** save édition |
**Ne pas** implémenter le mode `edit` ni le switch 2ᵉ parent → **#135**.
Si louverture « review » dun dossier actif est trop lourde pour ce ticket : clic peut temporairement no-op / snackbar *« Édition dossier : prochainement (#135) »***à éviter** si `getDossierByNumero` + wizard review marche déjà pour les deux types.
---
## Données / APIs (front)
### Déjà disponibles (préférer composer côté front pour #153)
| Besoin | API / service |
|--------|----------------|
| Pending AM | `getPendingUsers(role: assistante_maternelle)` |
| Pending familles | `getPendingFamilies()` |
| Parents (avec `numero_dossier`) | `getParents()` |
| AM (avec `numero_dossier`) | `getAssistantesMaternelles()` |
| Détail unifié | `getDossierByNumero(numero)``GET /dossiers/:numeroDossier` |
**Pas dendpoint `GET /dossiers` liste** aujourdhui. Pour #153 :
- Construire la liste unifiée **côté client** à partir de `getParents()` + `getAssistantesMaternelles()` (group by `numero_dossier`).
- Exclure ou marquer les pending déjà dans la section haute (éviter doublons visuels, ou les laisser dans les deux avec badge « à valider » — **préférence** : pending **uniquement** en haut ; liste basse = tous **hors** pending **ou** tous avec badge ; choisir une règle claire et documenter dans le PR).
**Règle recommandée** :
- Haut = pending only
- Bas = **tous** les dossiers ayant un `numero_dossier` (y compris pending) **OU** bas = non-pending only
**Recommandation produit** : bas = **tous** (vision complète), pending aussi en haut pour action rapide. Si doublon gênant : bas = non-pending only.
### Si le back ajoute plus tard `GET /dossiers`
Brancher `UserService.getDossiers()` — hors scope bloquant #153 front si composition client OK.
---
## Fichiers front probables
| Fichier | Rôle |
|---------|------|
| `frontend/lib/widgets/admin/user_management_panel.dart` | Onglet permanent **Dossiers** ; retirer logique conditionnelle À valider ; search sur cet onglet |
| `frontend/lib/widgets/admin/pending_validation_widget.dart` | Réemploi section haute (ou refactor léger) |
| **Nouveau** `…/dossiers_management_widget.dart` (nom libre) | Shell onglet : pending + liste unifiée + refresh |
| **Nouveau** modèle léger `DossierListItem` (type, numero, libelle, emails, statut…) | Mapping parents/AM → ligne |
| `user_service.dart` / `api_config.dart` | Seulement si helper `getDossiersUnified()` côté client (pas forcément nouvel endpoint) |
| `validation_dossier_modal.dart` | Réemploi ouverture pending / détail |
Réutiliser look & feel cartes / hover « Ouvrir » de `_PendingValidationRow` / `AdminUserCard`.
---
## Hors scope (#153)
- Bouton créer dossier
- Mode `edit` wizard + ajout 2ᵉ parent → **#135**
- Suppressions → **#154**
- Famille N responsables → **#139**
- Changer les onglets Parents / AM / Enfants (restent)
---
## Critères dacceptation front
- [ ] Onglet **Dossiers** toujours visible (même 0 pending)
- [ ] Plus donglet conditionnel **« À valider »**
- [ ] Section haute pending si non vide ; validation au clic OK
- [ ] Liste unifiée familles + AM en dessous ; 1 ligne / `numero_dossier`
- [ ] Couleur + icône différencient famille / AM
- [ ] Recherche filtre (n° + nom + email minimum)
- [ ] **Aucun** bouton créer dans cet onglet
- [ ] Pas de régression validation pending (valider / refuser)
---
## Back (info — Cursor back séparé si besoin)
- Liste unifiée : **pas bloquante** si composition front
- Optionnel : `GET /api/v1/dossiers` (liste) pour perf / pagination plus tard
- `GET /dossiers/:numero` déjà là (#119)
---
## Branche
`feature/153-onglet-dossiers` (depuis `develop`)
-35
View File
@@ -1,35 +0,0 @@
# Matrice suppression — #154 / back **#159** / front **#160**
**Statut** : cadrage PO validé (sept. 2026)
**Milestone** : 0.1.0
**Email** : pas demail de suppression (cas rare)
## Droits
| Cible | Qui peut supprimer |
|-------|-------------------|
| Dossier / parent / enfant / AM | `GESTIONNAIRE`, `ADMINISTRATEUR`, `SUPER_ADMIN` |
| Gestionnaire (user) | `ADMINISTRATEUR`, `SUPER_ADMIN` |
| Administrateur (user) | Autre admin OK ; **self interdit** ; **dernier admin** = `SUPER_ADMIN` only ; `SUPER_ADMIN` non supprimable |
## Matrice métier
| Point dentrée | Action | Effet |
|----------------|--------|--------|
| Dossiers | Delete dossier **famille** | Tous **parents** + tous **enfants** ; clore placements AM des enfants |
| Dossiers / AM | Delete dossier **AM** ou compte AM | **Compte AM + dossier AM** ; enfants **conservés** ; placements **clos** |
| Parents | Co-parent (autre parent reste) | Compte parent seul ; dossier + enfants restent |
| Parents | Dernier parent | Parent + **enfants** rattachés |
| Enfants | Pas dernier | Enfant seul (retiré du dossier) |
| Enfants | Dernier + `deleteDossier=true` | Cascade dossier famille (parents + enfants) |
| Enfants | Dernier + `deleteDossier=false` | Enfant seul ; dossier peut apparaître **`sans_enfant`** |
| Pending / validé | — | **Mêmes règles** (pas de différenciation) |
## Warning
- `sans_enfant` sur liste `GET /dossiers` (dossier famille sans enfant lié).
- Miroir de `sans_responsable` (#157) côté enfants.
## Hors scope
Soft-delete RGPD, audit (#128), famille N (#139), restriction admin-only métier (plus tard).
-169
View File
@@ -1,169 +0,0 @@
# Mini-spec front — Suppressions dashboard
**Ticket front** : **#160** — https://git.ptits-pas.fr/jmartin/petitspas/issues/160
**Ticket back** : **#159** — https://git.ptits-pas.fr/jmartin/petitspas/issues/159
**Epic** : #154 (complète #133)
**Branche back** : `feature/159-suppressions-backend`
**Doc matrice** : [154-matrice-suppression.md](./154-matrice-suppression.md)
Travail **en parallèle** : ce contrat est la source de vérité UI ↔ API.
---
## UX commune
Sur chaque ligne / carte des listes :
- Icône **poubelle** en bout de ligne
- Clic → **dialog de confirmation** (texte dimpact) → DELETE → **refresh** liste
- Pending = **mêmes** règles que validés
- **Pas** demail
| Liste | Poubelle visible si |
|-------|---------------------|
| Dossiers, Parents, Enfants, AM | gestionnaire **ou** admin |
| Gestionnaires | **admin** only |
| Administrateurs | admin+ ; **pas** sur sa propre ligne ; dernier admin : UI warning + réservé super_admin |
---
## Contrat API
Base : auth Bearer. Erreurs : `400` / `403` / `404` / `409` avec `message` FR.
### 1. `DELETE /dossiers/:numeroDossier`
- **Famille** → supprime tous parents + enfants du n° ; clos placements AM des enfants.
- **AM** → compte AM + dossier AM ; enfants gardés ; placements clos.
**Réponse 200** (exemple) :
```json
{
"type": "famille",
"numero_dossier": "2026-000043",
"deleted_user_ids": ["…"],
"deleted_enfant_ids": ["…"],
"message": "Dossier famille supprimé."
}
```
ou
```json
{
"type": "assistante_maternelle",
"numero_dossier": "2026-000015",
"deleted_user_ids": ["…"],
"deleted_enfant_ids": [],
"message": "Dossier assistante maternelle supprimé."
}
```
**Dialog UI** : lister libellé + n° + « X parent(s), Y enfant(s) » (ou « compte AM, enfants conservés »).
---
### 2. `DELETE /users/:id`
Comportement selon le **rôle** de la cible :
| Cible | Effet |
|-------|--------|
| Parent **co-parent** | Delete ce user seul |
| Parent **dernier** du dossier | Delete user + enfants du foyer |
| AM | Delete user AM + dossier AM ; enfants conservés ; placements clos |
| Gestionnaire | Admin only ; self → 403 |
| Administrateur | Self → 403 ; dernier admin → super_admin only sinon 403 ; super_admin → 403 |
**Réponse 200** :
```json
{
"deleted_user_ids": ["…"],
"deleted_enfant_ids": ["…"],
"message": "…"
}
```
**Dialogs** :
- Co-parent : « Ce parent sera retiré / supprimé du dossier {n°}. Les enfants restent avec le co-parent. »
- Dernier parent : « Dernier parent du dossier {n°}. Les enfants rattachés seront aussi supprimés. »
- AM : « Le compte et le dossier AM seront supprimés. Les enfants accueillis ne seront pas supprimés. »
Optionnel (si exposé) : `GET /users/:id/suppression-impact` — sinon calculer depuis données déjà en liste / détail dossier.
---
### 3. `DELETE /enfants/:id?deleteDossier=true|false`
- Pas dernier enfant → delete enfant (`deleteDossier` ignoré ou false).
- Dernier enfant + `deleteDossier=false` → delete enfant ; dossier famille peut passer `sans_enfant`.
- Dernier enfant + `deleteDossier=true` → cascade dossier famille (parents + enfants).
**Réponse 200** :
```json
{
"deleted_enfant_ids": ["…"],
"deleted_user_ids": ["…"],
"dossier_supprime": false,
"message": "…"
}
```
**Dialog** :
- Standard : « Lenfant sera supprimé du dossier de {famille} ({n°}). »
- Dernier : proposer **deux actions** :
1. Supprimer lenfant seulement (`deleteDossier=false`)
2. Supprimer aussi le dossier / parents (`deleteDossier=true`)
Pour savoir si dernier : compter enfants du `numero_dossier` (détail dossier ou champ impact API).
---
### 4. `GET /dossiers` — flag `sans_enfant`
Chaque item famille peut exposer :
```json
"sans_enfant": true
```
- `true` si dossier **famille** sans enfant lié.
- AM : `false` ou omis.
**UI** : badge / warning vigilance (comme `sans_responsable` / alertes AM).
---
## UserService (Flutter) — signatures cibles
```dart
Future<void> deleteDossier(String numeroDossier);
Future<Map<String, dynamic>> deleteUser(String userId);
Future<Map<String, dynamic>> deleteEnfant(String enfantId, {bool deleteDossier = false});
```
(Adapter le parsing au JSON réel une fois le back mergé ; en parallèle, stubber sur ce contrat.)
---
## Fichiers front probables
- Cartes listes : `admin_user_card.dart`, `admin_enfant_user_card.dart`, cartes dossiers
- Listes : `dossiers_management_widget.dart`, `parent_managmant_widget.dart`, `enfant_management_widget.dart`, `assistante_maternelle_management_widget.dart`, `gestionnaire_management_widget.dart`, `admin_management_widget.dart`
- `user_service.dart`
---
## Critères front (#160)
- [ ] Poubelle selon droits
- [ ] Confirmations avec impact
- [ ] Refresh après succès
- [ ] Dernier enfant : choix dossier oui/non
- [ ] Warning `sans_enfant`
- [ ] Self-admin / dernier admin gérés côté UI (masquer ou message 403)
@@ -1,54 +0,0 @@
# Mini-spec — Rename préfixe `Admin*` dashboard partagé (#155)
**Ticket** : **#155**
**Branche** : `feature/155-rename-admin-prefix-dashboard` (depuis `develop`)
**Décision naming** : **option C** — dossier neutre `widgets/dashboard/` + noms **sans** préfixe `Admin`.
---
## Principe
Les widgets partagés **admin + gestionnaire** ne doivent plus sappeler `Admin*`.
On garde `Admin*` seulement là où cest vraiment le rôle administrateur.
## Gardé `Admin*` (hors rename)
| Élément | Raison |
|---------|--------|
| `AdminManagementWidget` | Onglet **Administrateurs** |
| `screens/administrateurs/*` | `AdminDashboardScreen`, `AdminCreateDialog`, `AdminUserFormDialog` |
| `EnfantAdminModel` | Modèle API (pas un widget) — hors scope ticket |
## Renames faits
| Avant | Après |
|-------|--------|
| `widgets/admin/common/admin_child_detail_modal.dart``AdminChildDetailModal` | `widgets/dashboard/child_detail_modal.dart``ChildDetailModal` |
| `admin_am_edit_modal``AdminAmEditModal` | `am_edit_modal``AmEditModal` |
| `admin_parent_edit_modal``AdminParentEditModal` | `parent_edit_modal``ParentEditModal` |
| `admin_user_card``AdminUserCard` | `user_card``UserCard` |
| `admin_enfant_user_card``AdminEnfantUserCard` | `enfant_user_card``EnfantUserCard` |
| `admin_am_photo_frame``AdminAmPhotoFrame` | `am_photo_frame``AmPhotoFrame` |
| `admin_am_children_capacity_grid` | `am_children_capacity_grid``AmChildrenCapacityGrid` |
| `admin_children_affiliation_panel` | `children_affiliation_panel``ChildrenAffiliationPanel` |
| `admin_select_*` / `AdminSelect*` / `AdminFamilleFoyer` | `select_*` / `Select*` / `FamilleFoyer` |
| `admin_status_capsule` | `status_capsule``StatusCapsule` |
| `admin_list_state``AdminListState` | `user_list_state``UserListState` |
| `admin_detail_modal``AdminDetailModal` / `AdminDetailField` | `detail_modal``DetailModal` / `DetailField` |
| `dashboard_admin.dart` | `user_management_sub_bar.dart` (`DashboardUserManagementSubBar` inchangé) |
Dossier `widgets/admin/` conserve encore les panels métier (`user_management_panel`, wizards, etc.) + `AdminManagementWidget`.
**Phase 2** (même ticket #155) : déplacer ces panels → `widgets/dashboard/` — voir [155-suite-move-admin-panels-to-dashboard.md](./155-suite-move-admin-panels-to-dashboard.md).
## Hors scope
- Refonte UX modales (ticket dédié)
- Rename API / back
- Déplacer tout `widgets/admin/``widgets/dashboard/` (panels) — possible follow-up
## Critères
- [x] Plus de préfixe `Admin` sur les composants **partagés** listés
- [ ] Build Flutter / recette dashboard admin + gestionnaire OK
- [x] Pas de changement comportemental (rename mécanique)
@@ -1,203 +0,0 @@
# Mini-spec — Déplacer les panels `widgets/admin/``widgets/dashboard/`
**Ticket** : **#155** (phase 2 — même ticket que le rename `Admin*`)
**Phase 1** : widgets `Admin*``widgets/dashboard/` (déjà sur `feature/155-rename-admin-prefix-dashboard`)
**Branche** : poursuivre / rebaser `feature/155-rename-admin-prefix-dashboard` (ou nouvelle branche depuis `develop` après merge phase 1)
**Nature** : rename / move mécanique — **zéro** changement UX / métier
---
## Contexte
Après la phase 1 (#155), la situation est **hybride** :
| Emplacement | Contenu |
|-------------|---------|
| `widgets/dashboard/` | Composants partagés sans préfixe `Admin*` (modales, cartes, selects, sub-bar…) |
| `widgets/admin/` | **Panels** du dashboard staff (listes, wizards, validation, shell `UserManagementPanel`…) + `AdminManagementWidget` |
Le dossier `admin/` laisse encore croire « réservé administrateur », alors que **gestionnaire** consomme les mêmes panels (`GestionnaireDashboardScreen``UserManagementPanel`).
Ce ticket **termine loption C** au niveau dossier : tout le dashboard staff vit sous `widgets/dashboard/`, sauf ce qui est **vraiment** rôle admin.
---
## Objectif
```
frontend/lib/widgets/admin/<panels & common partagés>
↓ git mv + update imports
frontend/lib/widgets/dashboard/…
```
Critère : un nouveau dev ne doit plus ouvrir `widgets/admin/` pour du code partagé admin+gestionnaire.
---
## Cible darborescence (proposée)
```
widgets/dashboard/
├── (déjà là #155) child_detail_modal.dart, am_edit_modal.dart, user_card.dart, …
├── user_management_panel.dart ← shell onglets
├── user_management_sub_bar.dart ← déjà déplacé #155
├── dossiers_management_widget.dart
├── dossier_list_card.dart
├── parent_management_widget.dart ← corriger le typo managmant au passage ?
├── enfant_management_widget.dart
├── assistante_maternelle_management_widget.dart
├── gestionnaire_management_widget.dart
├── pending_validation_widget.dart
├── parent_dossier_create_modal.dart
├── parent_dossier_wizard.dart
├── am_dossier_create_modal.dart
├── am_dossier_wizard.dart
├── validation_*.dart ← family/am wizards, refus, theme, confirm
├── parametres_panel.dart ← utilisé par écran admin (OK dans dashboard)
├── relais_management_panel.dart
├── common/ ← sous-dossier optionnel
│ ├── suppression_confirm_dialog.dart
│ ├── user_list.dart
│ └── validation_detail_section.dart
└── …
widgets/admin/ ← mince, rôle admin seulement
└── admin_management_widget.dart ← onglet Administrateurs
```
### Variante B (plus stricte)
`AdminManagementWidget` + éventuels helpers purement admin →
`screens/administrateurs/widgets/`
et **suppression** du dossier `widgets/admin/`.
**Reco** : **variante A** (garder `widgets/admin/` minimal avec seulement `AdminManagementWidget`) — moins de churn screens, clair.
---
## Inventaire à déplacer (état actuel)
### Racine `widgets/admin/``widgets/dashboard/`
| Fichier actuel | Notes |
|----------------|--------|
| `user_management_panel.dart` | Shell partagé admin + gestionnaire |
| `dossiers_management_widget.dart` | |
| `dossier_list_card.dart` | |
| `parent_managmant_widget.dart` | Typo historique `managmant`**option** : renommer → `parent_management_widget.dart` dans le même ticket ou ticket typo séparé |
| `enfant_management_widget.dart` | |
| `assistante_maternelle_management_widget.dart` | |
| `gestionnaire_management_widget.dart` | |
| `pending_validation_widget.dart` | |
| `parent_dossier_create_modal.dart` | |
| `parent_dossier_wizard.dart` | |
| `am_dossier_create_modal.dart` | |
| `am_dossier_wizard.dart` | |
| `validation_am_wizard.dart` | |
| `validation_family_wizard.dart` | |
| `validation_dossier_modal.dart` | |
| `validation_modal_theme.dart` | |
| `validation_refus_form.dart` | |
| `validation_valider_confirm_dialog.dart` | |
| `parametres_panel.dart` | Écran admin seulement, mais pas préfixé Admin — OK dashboard |
| `relais_management_panel.dart` | |
### `widgets/admin/common/``widgets/dashboard/common/` (ou plat)
| Fichier | Notes |
|---------|--------|
| `suppression_confirm_dialog.dart` | Partagé (y compris `screens/administrateurs/creation/*`) |
| `user_list.dart` | |
| `validation_detail_section.dart` | |
### **Ne pas** déplacer
| Fichier | Destination |
|---------|-------------|
| `admin_management_widget.dart` | Reste `widgets/admin/` (ou variante B → screens) |
### Déjà fait (#155) — ne pas retraiter
Tout ce qui est déjà sous `widgets/dashboard/` (`child_detail_modal`, `am_edit_modal`, `user_card`, `select_*`, `user_management_sub_bar`, …).
---
## Consommateurs dimports (à mettre à jour)
### Screens
- `screens/administrateurs/admin_dashboardScreen.dart``UserManagementPanel`, `ParametresPanel`
- `screens/gestionnaire/gestionnaire_dashboard_screen.dart``UserManagementPanel`
- `screens/administrateurs/creation/admin_create.dart``suppression_confirm_dialog`
- `screens/administrateurs/creation/gestionnaires_create.dart` — idem
### Widgets déjà en `dashboard/`
- `am_edit_modal`, `child_detail_modal`, `parent_edit_modal`, `select_*` — imports vers `widgets/admin/common/*` ou panels
### Divers
- `widgets/common/identity_block.dart` (si import admin)
- Tous les fichiers **déplacés** entre eux (imports relatifs / package)
### Hors scope rename classes
Sauf décision explicite sur le typo `parent_managmant_widget` → pas de rename de **classes** métier dans ce ticket (seulement chemins de fichiers + imports).
`AdminManagementWidget` **conserve** son nom.
---
## Plan dexécution
1. Partir de `feature/155-rename-admin-prefix-dashboard` (phase 1) **ou** `develop` si phase 1 déjà mergée
2. `git mv` fichiers selon inventaire
3. Remplacer globalement
`package:p_tits_pas/widgets/admin/``package:p_tits_pas/widgets/dashboard/`
**sauf** `…/widgets/admin/admin_management_widget.dart`
4. Corriger imports relatifs cassés
5. Grep de contrôle (ci-dessous)
6. Build Flutter web (Docker) + smoke dashboard admin **et** gestionnaire
7. Merge → squash master si flux habituel
---
## Vérifs
```bash
# Plus de panels partagés sous admin (seul AdminManagement attendu)
find frontend/lib/widgets/admin -name '*.dart'
# Plus dimports panels vers lancien chemin (sauf AdminManagement)
rg -n "widgets/admin/(user_management|dossiers_|parent_|enfant_|assistante|gestionnaire|pending|validation_|parametres|relais|am_dossier|parent_dossier|dossier_list|common/)" frontend/lib
# Screens OK
rg -n "widgets/admin/" frontend/lib/screens
```
Attendu screens : **0** hit vers panels ; éventuellement plus aucun hit `widgets/admin/` sauf si import explicite `AdminManagementWidget` depuis `user_management_panel` (chemin `widgets/admin/admin_management_widget.dart`).
---
## Hors scope
- Refonte UX des modales / panels (ticket dédié annoncé)
- Rename `EnfantAdminModel`
- Rename `screens/administrateurs/`
- Rename `AdminUserFormDialog` / `AdminCreateDialog`
- Changement API / back
- #152 (`est_multiple`) — autre branche
---
## Critères dacceptation
- [ ] Inventaire déplacé selon tableau
- [ ] `widgets/admin/` ne contient plus que `admin_management_widget.dart` (variante A)
- [ ] Imports screens + widgets à jour
- [ ] Build Flutter OK
- [ ] Recette : dashboard **administrateur** et **gestionnaire** (listes, ouverture fiches, validation, création dossier) sans régression
- [ ] Aucun changement comportemental volontaire
---
## Risques / notes
- **Conflits de merge** si dautres features touchent les panels → faire ce ticket quand la surface dashboard est calme (fin 0.1.0 OK)
- Typo `parent_managmant_widget` : soit inclus (bonus), soit ticket cleanup 1-ligne séparé
- Docs darchive citant `widgets/admin/…` : pas obligatoire de mettre à jour ; `docs/27_BRIEFING-FRONTEND.md` oui si encore listé
-75
View File
@@ -1,75 +0,0 @@
# Mini-spec API — POST /assistantes-maternelles/dossier (#156)
Contrat pour le **plan front** (wizard création AM staff).
## Endpoint
| | |
|--|--|
| **Méthode** | `POST` |
| **URL** | `{base}/assistantes-maternelles/dossier` |
| **Auth** | Bearer JWT |
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
| **Content-Type** | `application/json` |
Ne **pas** appeler `POST /auth/register/am` depuis le dashboard.
## Body (JSON)
Aligné inscription AM publique, **sans** CGU/privacy obligatoires (acceptées serveur).
| Champ | Type | Obligatoire | Notes |
|-------|------|-------------|--------|
| `email` | string | oui | unique |
| `prenom` | string | oui | |
| `nom` | string | oui | |
| `telephone` | string | oui | `0X…` ou `+33…` |
| `adresse` | string | non | |
| `code_postal` | string | non | |
| `ville` | string | non | |
| `photo_base64` | string | non | data-URL `data:image/…;base64,…` |
| `photo_filename` | string | non | hint nom fichier |
| `consentement_photo` | bool | oui | |
| `date_naissance` | date ISO | non | `YYYY-MM-DD` |
| `lieu_naissance_ville` | string | oui | |
| `lieu_naissance_pays` | string | oui | |
| `nir` | string | oui | 15 car. (Corse 2A/2B OK) |
| `numero_agrement` | string | oui | unique |
| `date_agrement` | date ISO | non | |
| `capacite_accueil` | int | oui | 110 |
| `places_disponibles` | int | oui | 010, ≤ capacité |
| `biographie` | string | non | max 2000 |
## Réponses
### 201 Created
```json
{
"message": "Dossier AM créé et validé. Un e-mail de création de mot de passe a été envoyé.",
"user_id": "uuid",
"statut": "actif",
"numero_dossier": "2026-000042"
}
```
Effets serveur : user AM **actif**, fiche `assistantes_maternelles`, n° dossier, **e-mail création MDP** (pas daccusé « en attente »).
### Erreurs
| Code | Cas |
|------|-----|
| 400 | Validation / NIR / places > capacité |
| 403 | Rôle non staff |
| 409 | Email, NIR ou agrément déjà pris |
| 401 | Token manquant / invalide |
## Front
- `UserService.createAmDossier(body)` → cet endpoint
- Après 201 : refresh liste AM ; snackbar OK
- Wizard create : ne pas envoyer `acceptation_cgu` / `acceptation_privacy` (optionnels)
## Branche
`feature/156-creation-dossier-am`
@@ -1,14 +0,0 @@
# Mini-spec — Uniformisation modale staff (Gestionnaire / Administrateur)
**Ticket** : **#164** — https://git.ptits-pas.fr/jmartin/petitspas/issues/164
**Branche** : `feature/164-staff-modal-uniformisation` (depuis `develop`)
**Périmètre** : **front only** — pas dAPI / BDD
**Milestone** : **0.1.0**
Voir le corps du ticket #164 pour la spec complète.
## Livré
- `frontend/lib/widgets/dashboard/staff_user_form_modal.dart``StaffUserFormModal`
- Ancien `AdminUserFormDialog` / `gestionnaires_create.dart` retiré
- Imports : `user_management_panel`, `gestionnaire_management_widget`, `admin_management_widget`
Binary file not shown.

After

Width:  |  Height:  |  Size: 216 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 249 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 277 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 171 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 290 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 239 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 441 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 169 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 223 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 253 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 217 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 289 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

+113
View File
@@ -0,0 +1,113 @@
/// Modèles du couple de garde (enfant ↔ AM) — ticket #167.
/// Contrat backend #168 : GET /parents/me/couples-garde.
/// Identité minimale d'une personne du couple (enfant, AM ou parent).
class CoupleMembre {
final String id;
final String? prenom;
final String? nom;
final String? photoUrl;
const CoupleMembre({
required this.id,
this.prenom,
this.nom,
this.photoUrl,
});
/// Nom d'affichage : prénom seul si dispo, sinon « Prénom Nom », sinon repli.
String displayName({String fallback = ''}) {
final p = (prenom ?? '').trim();
final n = (nom ?? '').trim();
if (p.isNotEmpty && n.isNotEmpty) return '$p $n';
if (p.isNotEmpty) return p;
if (n.isNotEmpty) return n;
return fallback;
}
factory CoupleMembre.fromJson(Map<String, dynamic> json) {
return CoupleMembre(
id: (json['id'] ?? '').toString(),
prenom: json['prenom']?.toString(),
nom: json['nom']?.toString(),
photoUrl: json['photo_url']?.toString(),
);
}
}
/// Un couple de garde = placement actif enfant ↔ AM.
class CoupleGarde {
final String id;
final CoupleMembre enfant;
final CoupleMembre am;
final bool courant;
const CoupleGarde({
required this.id,
required this.enfant,
required this.am,
this.courant = false,
});
factory CoupleGarde.fromJson(Map<String, dynamic> json) {
return CoupleGarde(
id: (json['id'] ?? '').toString(),
enfant: CoupleMembre.fromJson(
Map<String, dynamic>.from(json['enfant'] ?? const {}),
),
am: CoupleMembre.fromJson(
Map<String, dynamic>.from(json['am'] ?? const {}),
),
courant: json['courant'] == true,
);
}
CoupleGarde copyWith({bool? courant}) {
return CoupleGarde(
id: id,
enfant: enfant,
am: am,
courant: courant ?? this.courant,
);
}
}
/// Réponse de l'API couples de garde (liste + id du couple courant).
class CouplesGardeResponse {
final List<CoupleGarde> couples;
final String? coupleCourantId;
const CouplesGardeResponse({
required this.couples,
this.coupleCourantId,
});
bool get isEmpty => couples.isEmpty;
bool get isUnique => couples.length == 1;
/// Couple courant : celui marqué `courant`, sinon celui de [coupleCourantId],
/// sinon le premier (repli implicite côté client, prévu par le back).
CoupleGarde? get coupleCourant {
if (couples.isEmpty) return null;
for (final c in couples) {
if (c.courant) return c;
}
if (coupleCourantId != null) {
for (final c in couples) {
if (c.id == coupleCourantId) return c;
}
}
return couples.first;
}
factory CouplesGardeResponse.fromJson(Map<String, dynamic> json) {
final list = (json['couples'] as List?) ?? const [];
return CouplesGardeResponse(
couples: list
.whereType<Map>()
.map((e) => CoupleGarde.fromJson(Map<String, dynamic>.from(e)))
.toList(),
coupleCourantId: json['couple_courant_id']?.toString(),
);
}
}
@@ -1,41 +1,36 @@
import 'package:flutter/material.dart'; import 'package:flutter/material.dart';
import 'package:p_tits_pas/controllers/parent_dashboard_controller.dart'; import 'package:p_tits_pas/models/couple_garde.dart';
import 'package:p_tits_pas/models/user.dart'; import 'package:p_tits_pas/models/user.dart';
import 'package:p_tits_pas/services/auth_service.dart'; import 'package:p_tits_pas/services/auth_service.dart';
import 'package:p_tits_pas/services/dashboardService.dart'; import 'package:p_tits_pas/services/couple_garde_service.dart';
import 'package:p_tits_pas/widgets/app_footer.dart'; import 'package:p_tits_pas/widgets/quotidien/couple_selector_bandeau.dart';
import 'package:p_tits_pas/widgets/dashbord_parent/children_sidebar.dart'; import 'package:p_tits_pas/widgets/quotidien/quotidien_shell.dart';
import 'package:p_tits_pas/widgets/dashbord_parent/wid_dashbord.dart'; import 'package:p_tits_pas/widgets/quotidien/quotidien_theme.dart';
import 'package:p_tits_pas/widgets/dashboard/dashboard_bandeau.dart';
import 'package:p_tits_pas/widgets/main_content_area.dart';
import 'package:p_tits_pas/widgets/messaging_sidebar.dart';
import 'package:provider/provider.dart';
/// Tableau de bord parent — coquille 3 colonnes quotidien (#166).
/// Colonne gauche : sélecteur de couple enfantnounou (#167).
/// Métier cartes / blog / messagerie : tickets C/D/E.
class ParentDashboardScreen extends StatefulWidget { class ParentDashboardScreen extends StatefulWidget {
const ParentDashboardScreen({Key? key}) : super(key: key); const ParentDashboardScreen({super.key});
@override @override
State<ParentDashboardScreen> createState() => _ParentDashboardScreenState(); State<ParentDashboardScreen> createState() => _ParentDashboardScreenState();
} }
class _ParentDashboardScreenState extends State<ParentDashboardScreen> { class _ParentDashboardScreenState extends State<ParentDashboardScreen> {
int selectedIndex = 0; QuotidienNavSection _section = QuotidienNavSection.liaison;
AppUser? _user; AppUser? _user;
void onTabChange(int index) { List<CoupleGarde> _couples = const [];
setState(() { String? _selectedCoupleId;
selectedIndex = index; bool _couplesLoading = true;
}); String? _couplesError;
}
@override @override
void initState() { void initState() {
super.initState(); super.initState();
_loadUser(); _loadUser();
// Initialiser les données du dashboard _loadCouples();
WidgetsBinding.instance.addPostFrameCallback((_) {
context.read<ParentDashboardController>().initDashboard();
});
} }
Future<void> _loadUser() async { Future<void> _loadUser() async {
@@ -43,222 +38,152 @@ class _ParentDashboardScreenState extends State<ParentDashboardScreen> {
if (mounted) setState(() => _user = user); if (mounted) setState(() => _user = user);
} }
Widget _getBody() { Future<void> _loadCouples() async {
switch (selectedIndex) { setState(() {
case 0: _couplesLoading = true;
return Dashbord_body(); _couplesError = null;
case 1: });
return const Center(child: Text("🔍 Trouver une nounou")); try {
case 2: final res = await CoupleGardeService.getCouplesGarde();
return const Center(child: Text("⚙️ Paramètres")); if (!mounted) return;
default: setState(() {
return const Center(child: Text("Page non trouvée")); _couples = res.couples;
_selectedCoupleId = res.coupleCourant?.id;
_couplesLoading = false;
});
} catch (e) {
if (!mounted) return;
setState(() {
_couplesError = e.toString().replaceFirst('Exception: ', '');
_couplesLoading = false;
});
} }
} }
Future<void> _selectCouple(CoupleGarde couple) async {
if (couple.id == _selectedCoupleId) return;
// Optimiste : on bascule tout de suite, l'API persiste ensuite.
setState(() => _selectedCoupleId = couple.id);
try {
final res = await CoupleGardeService.definirCoupleCourant(couple.id);
if (!mounted) return;
setState(() {
_couples = res.couples;
_selectedCoupleId = res.coupleCourant?.id ?? couple.id;
});
} catch (e) {
if (!mounted) return;
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text(
'Impossible de changer de garde : '
'${e.toString().replaceFirst('Exception: ', '')}',
),
),
);
}
}
String get _displayName {
final n = _user?.fullName.trim() ?? '';
if (n.isNotEmpty) return n;
final email = _user?.email.trim() ?? '';
if (email.isNotEmpty) return email.split('@').first;
return 'Parent';
}
void _soon(String label) {
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(content: Text('$label — à venir')),
);
}
@override @override
Widget build(BuildContext context) { Widget build(BuildContext context) {
return ChangeNotifierProvider( return QuotidienShell(
create: (context) => ParentDashboardController(DashboardService())..initDashboard(), selectedSection: _section,
child: Scaffold( onSectionSelected: (s) => setState(() => _section = s),
appBar: PreferredSize( userDisplayName: _displayName,
preferredSize: const Size.fromHeight(60.0), userEmail: _user?.email,
child: DashboardBandeau( onProfileTap: () => _soon('Profil'),
tabItems: const [ onSearchAmTap: () => _soon('Recherche AM'),
DashboardTabItem(label: 'Mon tableau de bord'), onSettingsTap: () => _soon('Paramètres'),
DashboardTabItem(label: 'Trouver une nounou'), leftColumn: _LeftColumn(
DashboardTabItem(label: 'Paramètres'), couples: _couples,
], selectedCoupleId: _selectedCoupleId,
selectedTabIndex: selectedIndex, loading: _couplesLoading,
onTabSelected: onTabChange, error: _couplesError,
userDisplayName: _user?.fullName.isNotEmpty == true onRetry: _loadCouples,
? _user!.fullName onCoupleSelected: _selectCouple,
: 'Parent', ),
userEmail: _user?.email, centerColumn: const QuotidienColumnPlaceholder(
userRole: _user?.role, title: 'Blog',
onProfileTap: () { subtitle:
ScaffoldMessenger.of(context).showSnackBar( 'Fil du quotidien (affichage par défaut)\n(à brancher — ticket #178).',
const SnackBar( icon: Icons.auto_stories_outlined,
content: Text('Modification du profil à venir')), ),
); rightColumn: const QuotidienColumnPlaceholder(
}, title: 'Messagerie',
onSettingsTap: () { subtitle:
ScaffoldMessenger.of(context).showSnackBar( 'Mess. AM · Mess. RPE\n(à brancher — ticket #184).',
const SnackBar(content: Text('Paramètres à venir')), icon: Icons.chat_bubble_outline,
); ),
}, agendaBody: const QuotidienStubPage(
onLogout: () {}, title: 'Agenda',
showLogoutConfirmation: true, message: 'Agenda — contenu à venir (stub #187).',
), ),
), contratBody: const QuotidienStubPage(
body: Column( title: 'Contrat',
children: [ message: 'Contrat — contenu à venir (stub #187).',
Expanded(child: _getBody()),
const AppFooter(),
],
), ),
),
); );
} }
}
Widget _buildResponsiveBody(BuildContext context, ParentDashboardController controller) { /// Colonne gauche : bandeau couple (#167) puis flux de cartes (#173 à venir).
return LayoutBuilder( class _LeftColumn extends StatelessWidget {
builder: (context, constraints) { final List<CoupleGarde> couples;
if (constraints.maxWidth < 768) { final String? selectedCoupleId;
// Layout mobile : colonnes empilées final bool loading;
return _buildMobileLayout(controller); final String? error;
} else if (constraints.maxWidth < 1024) { final VoidCallback onRetry;
// Layout tablette : 2 colonnes final ValueChanged<CoupleGarde> onCoupleSelected;
return _buildTabletLayout(controller);
} else {
// Layout desktop : 3 colonnes
return _buildDesktopLayout(controller);
}
},
);
}
Widget _buildDesktopLayout(ParentDashboardController controller) { const _LeftColumn({
return Row( required this.couples,
crossAxisAlignment: CrossAxisAlignment.start, required this.selectedCoupleId,
children: [ required this.loading,
// Sidebar gauche - Enfants required this.error,
SizedBox( required this.onRetry,
width: 280, required this.onCoupleSelected,
child: ChildrenSidebar( });
children: controller.children,
selectedChildId: controller.selectedChildId,
onChildSelected: controller.selectChild,
onAddChild: controller.showAddChildModal,
),
),
// Contenu central
Expanded(
flex: 2,
child: MainContentArea(
selectedChild: controller.selectedChild,
selectedAssistant: controller.selectedAssistant,
events: controller.upcomingEvents,
contracts: controller.contracts,
),
),
// Sidebar droite - Messagerie
SizedBox(
width: 320,
child: MessagingSidebar(
conversations: controller.conversations,
notifications: controller.notifications,
),
),
],
);
}
Widget _buildTabletLayout(ParentDashboardController controller) { @override
return Row( Widget build(BuildContext context) {
children: [ return Padding(
// Sidebar enfants plus étroite padding: const EdgeInsets.all(14),
SizedBox(
width: 240,
child: ChildrenSidebar(
children: controller.children,
selectedChildId: controller.selectedChildId,
onChildSelected: controller.selectChild,
onAddChild: controller.showAddChildModal,
isCompact: true,
),
),
// Contenu principal avec messagerie intégrée
Expanded(
child: Column(
children: [
Expanded(
flex: 2,
child: MainContentArea(
selectedChild: controller.selectedChild,
selectedAssistant: controller.selectedAssistant,
events: controller.upcomingEvents,
contracts: controller.contracts,
),
),
SizedBox(
height: 200,
child: MessagingSidebar(
conversations: controller.conversations,
notifications: controller.notifications,
isCompact: true,
),
),
],
),
),
],
);
}
Widget _buildMobileLayout(ParentDashboardController controller) {
return DefaultTabController(
length: 4,
child: Column( child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [ children: [
// Navigation par onglets sur mobile CoupleSelectorBandeau(
Container( couples: couples,
color: Theme.of(context).primaryColor.withOpacity(0.1), selectedCoupleId: selectedCoupleId,
child: const TabBar( loading: loading,
isScrollable: true, errorMessage: error,
tabs: [ onRetry: onRetry,
Tab(text: 'Enfants', icon: Icon(Icons.child_care)), onCoupleSelected: onCoupleSelected,
Tab(text: 'Planning', icon: Icon(Icons.calendar_month)),
Tab(text: 'Contrats', icon: Icon(Icons.description)),
Tab(text: 'Messages', icon: Icon(Icons.message)),
],
),
), ),
const SizedBox(height: 14),
Expanded( const Expanded(
child: TabBarView( child: QuotidienColumnPlaceholder(
children: [ title: 'Cartes',
// Onglet Enfants subtitle:
ChildrenSidebar( 'Absences, congés AM, sorties à valider\n(à brancher — ticket #173).',
children: controller.children, icon: Icons.style_outlined,
selectedChildId: controller.selectedChildId,
onChildSelected: controller.selectChild,
onAddChild: controller.showAddChildModal,
isMobile: true,
),
// Onglet Planning
MainContentArea(
selectedChild: controller.selectedChild,
selectedAssistant: controller.selectedAssistant,
events: controller.upcomingEvents,
contracts: controller.contracts,
showOnlyCalendar: true,
),
// Onglet Contrats
MainContentArea(
selectedChild: controller.selectedChild,
selectedAssistant: controller.selectedAssistant,
events: controller.upcomingEvents,
contracts: controller.contracts,
showOnlyContracts: true,
),
// Onglet Messages
MessagingSidebar(
conversations: controller.conversations,
notifications: controller.notifications,
isMobile: true,
),
],
), ),
), ),
], ],
), ),
); );
} }
} }
@@ -62,6 +62,10 @@ class ApiConfig {
static const String parents = '/parents'; static const String parents = '/parents';
/// Création dossier famille actif par le staff (#129) — body type register parent. /// Création dossier famille actif par le staff (#129) — body type register parent.
static const String parentsDossier = '/parents/dossier'; static const String parentsDossier = '/parents/dossier';
/// Couples de garde du parent connecté (#167 / #168).
static const String parentsCouplesGarde = '/parents/me/couples-garde';
static const String parentsCoupleGardeCourant =
'/parents/me/couples-garde/courant';
static const String assistantesMaternelles = '/assistantes-maternelles'; static const String assistantesMaternelles = '/assistantes-maternelles';
/// Création dossier AM actif par le staff (#156) — body type register AM. /// Création dossier AM actif par le staff (#156) — body type register AM.
static const String assistantesMaternellesDossier = static const String assistantesMaternellesDossier =
@@ -0,0 +1,76 @@
import 'dart:convert';
import 'package:http/http.dart' as http;
import 'package:p_tits_pas/models/couple_garde.dart';
import 'package:p_tits_pas/services/api/api_config.dart';
import 'package:p_tits_pas/services/api/tokenService.dart';
/// Accès API aux couples de garde du parent connecté — tickets #167 / #168.
/// - GET /parents/me/couples-garde
/// - PUT /parents/me/couples-garde/courant { couple_id }
class CoupleGardeService {
static Future<Map<String, String>> _headers() async {
final token = await TokenService.getToken();
return token != null
? ApiConfig.authHeaders(token)
: Map<String, String>.from(ApiConfig.headers);
}
static String _extractError(String body, String fallback) {
try {
final decoded = jsonDecode(body);
if (decoded is Map<String, dynamic>) {
final message = decoded['message'];
if (message is String && message.trim().isNotEmpty) {
return message;
}
if (message is Map && message['message'] is String) {
return message['message'] as String;
}
}
} catch (_) {}
return fallback;
}
/// Liste les couples de garde et le couple courant du parent connecté.
static Future<CouplesGardeResponse> getCouplesGarde() async {
final response = await http.get(
Uri.parse('${ApiConfig.baseUrl}${ApiConfig.parentsCouplesGarde}'),
headers: await _headers(),
);
if (response.statusCode != 200) {
throw Exception(
_extractError(response.body, 'Erreur chargement des couples de garde'),
);
}
final decoded = jsonDecode(response.body);
return CouplesGardeResponse.fromJson(
Map<String, dynamic>.from(decoded as Map),
);
}
/// Persiste le couple courant (préférence utilisateur) et renvoie la liste
/// à jour.
static Future<CouplesGardeResponse> definirCoupleCourant(
String coupleId,
) async {
final response = await http.put(
Uri.parse('${ApiConfig.baseUrl}${ApiConfig.parentsCoupleGardeCourant}'),
headers: await _headers(),
body: jsonEncode({'couple_id': coupleId}),
);
if (response.statusCode != 200) {
throw Exception(
_extractError(response.body, 'Erreur sélection du couple de garde'),
);
}
final decoded = jsonDecode(response.body);
return CouplesGardeResponse.fromJson(
Map<String, dynamic>.from(decoded as Map),
);
}
}
+8 -4
View File
@@ -5,7 +5,11 @@ import 'package:p_tits_pas/models/m_dashbord/child_model.dart';
import 'package:p_tits_pas/services/bug_report_service.dart'; import 'package:p_tits_pas/services/bug_report_service.dart';
class AppFooter extends StatelessWidget { class AppFooter extends StatelessWidget {
const AppFooter({Key? key}) : super(key: key); /// Ligne grise droite au-dessus du footer. À désactiver quand l'écran
/// fournit déjà son propre séparateur (ex. trait crayon du quotidien).
final bool showTopBorder;
const AppFooter({Key? key, this.showTopBorder = true}) : super(key: key);
@override @override
Widget build(BuildContext context) { Widget build(BuildContext context) {
@@ -13,9 +17,9 @@ class AppFooter extends StatelessWidget {
padding: const EdgeInsets.symmetric(horizontal: 24, vertical: 16), padding: const EdgeInsets.symmetric(horizontal: 24, vertical: 16),
decoration: BoxDecoration( decoration: BoxDecoration(
// color: Colors.white, // color: Colors.white,
border: Border( border: showTopBorder
top: BorderSide(color: Colors.grey.shade300), ? Border(top: BorderSide(color: Colors.grey.shade300))
), : null,
), ),
child: LayoutBuilder( child: LayoutBuilder(
builder: (context, constraints) { builder: (context, constraints) {
@@ -1,58 +0,0 @@
import 'package:flutter/material.dart';
class Childrensidebarwidget extends StatelessWidget{
final void Function(String childId) onChildSelected;
const Childrensidebarwidget({
Key? key,
required this.onChildSelected,
}) : super(key: key);
@override
Widget build(BuildContext context) {
final children = [
{'id': '1', 'name': 'Léna', 'photo': null, 'status': 'Actif'},
{'id': '2', 'name': 'Noé', 'photo': null, 'status': 'Inactif'},
];
return Container(
color: const Color(0xFFF7F7F7),
padding: const EdgeInsets.all(16),
child: Column(
children: [
// Avatar parent + bouton
Row(
mainAxisAlignment: MainAxisAlignment.spaceBetween,
children: [
const CircleAvatar(radius: 24, child: Icon(Icons.person)),
IconButton(
icon: const Icon(Icons.add),
onPressed: () {
// Naviguer vers ajout d'enfant
},
)
],
),
const SizedBox(height: 16),
const Text("Mes enfants", style: TextStyle(fontWeight: FontWeight.bold)),
const SizedBox(height: 16),
// Liste des enfants
...children.map((child) {
return GestureDetector(
onTap: () => onChildSelected(child['id']!),
child: Card(
color: child['status'] == 'Actif' ? Colors.teal.shade50 : Colors.white,
child: ListTile(
leading: const CircleAvatar(child: Icon(Icons.child_care)),
title: Text(child['name']!),
subtitle: Text(child['status']!),
),
),
);
}).toList()
],
),
);
}
}
@@ -1,28 +0,0 @@
import 'package:flutter/material.dart';
class AppLayout extends StatelessWidget {
final PreferredSizeWidget appBar;
final Widget body;
final Widget? footer;
const AppLayout({
Key? key,
required this.appBar,
required this.body,
this.footer,
}) : super(key: key);
@override
Widget build(BuildContext context) {
return Scaffold(
backgroundColor: const Color(0xFFF5F7FA),
appBar: appBar,
body: Column(
children: [
Expanded(child: body),
if (footer != null) footer!,
],
),
);
}
}
@@ -1,203 +0,0 @@
import 'package:flutter/material.dart';
import 'package:p_tits_pas/models/m_dashbord/child_model.dart';
class ChildrenSidebar extends StatelessWidget {
final List<ChildModel> children;
final String? selectedChildId;
final Function(String) onChildSelected;
final VoidCallback onAddChild;
final bool isCompact;
final bool isMobile;
const ChildrenSidebar({
Key? key,
required this.children,
this.selectedChildId,
required this.onChildSelected,
required this.onAddChild,
this.isCompact = false,
this.isMobile = false,
}) : super(key: key);
@override
Widget build(BuildContext context) {
return Container(
padding: EdgeInsets.all(isMobile ? 16 : 24),
color: Colors.white,
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
_buildHeader(context),
const SizedBox(height: 20),
_buildAddChildButton(context),
const SizedBox(height: 16),
Expanded(child: _buildChildrenList()),
],
),
);
}
Widget _buildHeader(BuildContext context) {
return Row(
children: [
// UserAvatar(
// size: isCompact ? 40 : 60,
// name: 'Emma Dupont', // TODO: Récupérer depuis le contexte utilisateur
// ),
if (!isCompact) ...[
const SizedBox(width: 12),
Expanded(
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: const [
Text(
'Emma Dupont',
style: TextStyle(
fontSize: 16,
fontWeight: FontWeight.w600,
),
),
Icon(Icons.keyboard_arrow_down),
],
),
),
],
],
);
}
Widget _buildAddChildButton(BuildContext context) {
return SizedBox(
width: double.infinity,
child: OutlinedButton.icon(
onPressed: onAddChild,
icon: const Icon(Icons.add),
label: Text(isCompact ? 'Ajouter' : 'Ajouter un enfant'),
style: OutlinedButton.styleFrom(
padding: EdgeInsets.symmetric(
horizontal: 16,
vertical: isCompact ? 8 : 12,
),
shape: RoundedRectangleBorder(
borderRadius: BorderRadius.circular(8),
),
),
),
);
}
Widget _buildChildrenList() {
if (children.isEmpty) {
return const Center(
child: Text(
'Aucun enfant ajouté',
style: TextStyle(
color: Colors.grey,
fontSize: 14,
),
),
);
}
return ListView.separated(
itemCount: children.length,
separatorBuilder: (context, index) => const SizedBox(height: 12),
itemBuilder: (context, index) {
final child = children[index];
final isSelected = child.id == selectedChildId;
return _buildChildCard(context, child, isSelected);
},
);
}
Widget _buildChildCard(BuildContext context, ChildModel child, bool isSelected) {
return InkWell(
onTap: () => onChildSelected(child.id),
borderRadius: BorderRadius.circular(12),
child: Container(
padding: const EdgeInsets.all(16),
decoration: BoxDecoration(
color: isSelected ? const Color(0xFF9CC5C0).withOpacity(0.1) : Colors.transparent,
borderRadius: BorderRadius.circular(12),
border: Border.all(
color: isSelected ? const Color(0xFF9CC5C0) : Colors.grey.shade300,
width: isSelected ? 2 : 1,
),
),
child: Row(
children: [
// UserAvatar(
// // size: isCompact ? 32 : 40,
// // name: child.fullName,
// // imageUrl: child.photoUrl,
// ),
if (!isCompact) ...[
const SizedBox(width: 12),
Expanded(
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Text(
child.firstName,
style: TextStyle(
fontSize: 14,
fontWeight: isSelected ? FontWeight.w600 : FontWeight.w500,
),
),
const SizedBox(height: 4),
_buildChildStatus(child.status),
],
),
),
],
],
),
),
);
}
Widget _buildChildStatus(ChildStatus status) {
String label;
Color color;
switch (status) {
case ChildStatus.withAssistant:
label = 'En garde';
color = Colors.green;
break;
case ChildStatus.available:
label = 'Disponible';
color = Colors.blue;
break;
case ChildStatus.onHoliday:
label = 'En vacances';
color = Colors.orange;
break;
case ChildStatus.sick:
label = 'Malade';
color = Colors.red;
break;
case ChildStatus.searching:
label = 'Recherche AM';
color = Colors.purple;
break;
}
return Container(
padding: const EdgeInsets.symmetric(horizontal: 8, vertical: 2),
decoration: BoxDecoration(
color: color.withOpacity(0.1),
borderRadius: BorderRadius.circular(12),
),
child: Text(
label,
style: TextStyle(
fontSize: 11,
color: color,
fontWeight: FontWeight.w500,
),
),
);
}
}
@@ -1,31 +0,0 @@
import 'package:flutter/material.dart';
import 'package:p_tits_pas/widgets/dashbord_parent/ChildrenSidebarwidget.dart';
import 'package:p_tits_pas/widgets/dashbord_parent/children_sidebar.dart';
import 'package:p_tits_pas/widgets/dashbord_parent/wid_mainContentArea.dart';
import 'package:p_tits_pas/widgets/messaging_sidebar.dart';
Widget Dashbord_body() {
return Row(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [
// 1️⃣ Colonne de gauche : enfants
SizedBox(
width: 250,
child: Childrensidebarwidget(
onChildSelected: (childId) {
// Met à jour l'enfant sélectionné
// Tu peux stocker cet ID dans un state `selectedChildId`
},
),
),
Expanded(
flex: 2,
child: WMainContentArea(
// Passe lenfant sélectionné si besoin
),
),
],
);
}
@@ -1,94 +0,0 @@
import 'package:flutter/material.dart';
import 'package:p_tits_pas/widgets/messaging_sidebar.dart';
class WMainContentArea extends StatelessWidget {
const WMainContentArea({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return Container(
padding: const EdgeInsets.all(16),
color: Colors.white,
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [
// 🔷 Informations assistante maternelle (ligne complète)
Card(
margin: const EdgeInsets.only(bottom: 16),
child: Padding(
padding: const EdgeInsets.all(16),
child: Row(
children: [
const CircleAvatar(
radius: 30,
backgroundImage: AssetImage("assets/images/am_photo.jpg"), // à adapter
),
const SizedBox(width: 16),
Expanded(
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: const [
Text("Julie Dupont", style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold)),
SizedBox(height: 4),
Text("Taux horaire : 10€/h"),
Text("Frais journaliers : 5€"),
],
),
),
ElevatedButton(
onPressed: () {
// Ouvrir le contrat
},
child: const Text("Voir le contrat"),
)
],
),
),
),
// 🔷 Deux colonnes : planning + messagerie
Expanded(
child: Row(
children: [
// 📆 Planning de garde
Expanded(
flex: 2,
child: Card(
child: Padding(
padding: const EdgeInsets.all(16),
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children: const [
Text("Planning de garde", style: TextStyle(fontSize: 16, fontWeight: FontWeight.bold)),
SizedBox(height: 12),
Expanded(
child: Center(
child: Text("Composant calendrier à intégrer ici"),
),
)
],
),
),
),
),
const SizedBox(width: 16),
// 💬 Messagerie
Expanded(
flex: 1,
child: MessagingSidebar(
conversations: [],
notifications: [],
isCompact: false,
isMobile: false,
),
),
],
),
)
],
),
);
}
}
+14 -2
View File
@@ -10,6 +10,14 @@ class ImageButton extends StatelessWidget {
final VoidCallback onPressed; final VoidCallback onPressed;
final double fontSize; // Ajout pour la flexibilité final double fontSize; // Ajout pour la flexibilité
/// Forme utilisée pour le focus / hover / splash. Les fonds « dessinés »
/// sont des pastilles : le stadium suit leur contour au lieu d'un rectangle.
final OutlinedBorder shape;
/// Opacité du fond seul (le texte reste net) : permet un état « inactif »
/// plus clair sans changer d'asset.
final double bgOpacity;
const ImageButton({ const ImageButton({
super.key, super.key,
required this.bg, required this.bg,
@@ -19,6 +27,8 @@ class ImageButton extends StatelessWidget {
required this.textColor, required this.textColor,
required this.onPressed, required this.onPressed,
this.fontSize = 16, // Valeur par défaut this.fontSize = 16, // Valeur par défaut
this.shape = const StadiumBorder(),
this.bgOpacity = 1.0,
}); });
@override @override
@@ -36,14 +46,16 @@ class ImageButton extends StatelessWidget {
style: TextButton.styleFrom( style: TextButton.styleFrom(
padding: EdgeInsets.zero, padding: EdgeInsets.zero,
tapTargetSize: MaterialTapTargetSize.shrinkWrap, tapTargetSize: MaterialTapTargetSize.shrinkWrap,
shape: shape: shape,
const RoundedRectangleBorder(borderRadius: BorderRadius.zero),
), ),
child: Ink( child: Ink(
// Pas de découpe du PNG : le trait « dessiné » déborde un peu du
// stadium, on ne rogne que le focus / hover / splash.
decoration: BoxDecoration( decoration: BoxDecoration(
image: DecorationImage( image: DecorationImage(
image: AssetImage(bg), image: AssetImage(bg),
fit: BoxFit.fill, fit: BoxFit.fill,
opacity: bgOpacity,
), ),
), ),
child: Center( child: Center(
@@ -0,0 +1,380 @@
import 'package:flutter/material.dart';
import 'package:google_fonts/google_fonts.dart';
import 'package:p_tits_pas/models/couple_garde.dart';
import 'package:p_tits_pas/services/api/api_config.dart';
import 'package:p_tits_pas/widgets/common/auth_network_image.dart';
import 'package:p_tits_pas/widgets/quotidien/quotidien_theme.dart';
/// Rôle qui consulte le bandeau : côté parent (enfant | nounou) ou côté AM
/// (enfant | parent(s)). Le composant est le même, seule la lecture change.
/// Ticket #167 (parent) ; #170 réutilise en mode AM.
enum CoupleBandeauMode { parent, assistanteMaternelle }
/// Bandeau « couple de garde » en haut de la colonne gauche du TdB.
///
/// - Plusieurs couples → contrôle unique avec chevron (dropdown de bascule).
/// - Un seul couple → affichage informatif (pas de chevron, pas de menu).
/// - Aucun couple → état vide discret.
class CoupleSelectorBandeau extends StatelessWidget {
final CoupleBandeauMode mode;
final List<CoupleGarde> couples;
final String? selectedCoupleId;
final ValueChanged<CoupleGarde>? onCoupleSelected;
final bool loading;
final String? errorMessage;
final VoidCallback? onRetry;
const CoupleSelectorBandeau({
super.key,
this.mode = CoupleBandeauMode.parent,
required this.couples,
this.selectedCoupleId,
this.onCoupleSelected,
this.loading = false,
this.errorMessage,
this.onRetry,
});
CoupleGarde? get _selected {
if (couples.isEmpty) return null;
if (selectedCoupleId != null) {
for (final c in couples) {
if (c.id == selectedCoupleId) return c;
}
}
for (final c in couples) {
if (c.courant) return c;
}
return couples.first;
}
@override
Widget build(BuildContext context) {
return LayoutBuilder(builder: (context, constraints) {
if (loading) return const _CoupleBandeauSkeleton();
if (errorMessage != null) {
return _CoupleBandeauError(message: errorMessage!, onRetry: onRetry);
}
if (couples.isEmpty) return const _CoupleBandeauEmpty();
final selected = _selected!;
final multi = couples.length > 1;
final card = _CoupleCard(
mode: mode,
couple: selected,
showChevron: multi,
colorIndex: couples.indexOf(selected),
);
if (!multi) return card;
return Theme(
data: Theme.of(context).copyWith(
hoverColor: Colors.transparent,
splashColor: Colors.transparent,
highlightColor: Colors.transparent,
focusColor: Colors.transparent,
),
child: PopupMenuButton<String>(
tooltip: 'Changer de garde',
// L'offset doit être suffisant pour descendre sous la carte (qui fait 90px).
offset: const Offset(0, 95),
color: Colors.transparent, // Le fond devient invisible
elevation: 0, // Pas d'ombre carrée
constraints: BoxConstraints.tightFor(width: constraints.maxWidth),
padding: EdgeInsets.zero,
onSelected: (id) {
final chosen = couples.firstWhere((c) => c.id == id);
onCoupleSelected?.call(chosen);
},
itemBuilder: (context) => [
for (final c in couples)
if (c.id != selected.id)
PopupMenuItem<String>(
value: c.id,
padding: EdgeInsets.zero,
height: 100, // Hauteur de la carte (90) + un peu de marge (10)
child: Padding(
padding: const EdgeInsets.only(bottom: 10),
child: _CoupleCard(
mode: mode,
couple: c,
showChevron: false,
selected: false,
isMenuItem: true,
colorIndex: couples.indexOf(c),
),
),
),
],
child: card,
),
);
});
}
}
/// Carte principale : enfant à gauche, séparateur, AM/parents à droite.
class _CoupleCard extends StatelessWidget {
final CoupleBandeauMode mode;
final CoupleGarde couple;
final bool showChevron;
final bool selected;
final bool isMenuItem;
final int colorIndex;
const _CoupleCard({
required this.mode,
required this.couple,
required this.showChevron,
this.selected = true,
this.isMenuItem = false,
required this.colorIndex,
});
@override
Widget build(BuildContext context) {
return Container(
height: 90,
decoration: BoxDecoration(
image: DecorationImage(
image: AssetImage(QuotidienTheme.bandeauColors[colorIndex % QuotidienTheme.bandeauColors.length]),
fit: BoxFit.fill,
),
),
padding: const EdgeInsets.symmetric(horizontal: 24),
child: Row(
children: [
Expanded(
child: Padding(
padding: const EdgeInsets.only(right: 12),
child: _MembreTile(
photoUrl: couple.enfant.photoUrl,
name: (couple.enfant.prenom != null && couple.enfant.prenom!.isNotEmpty)
? couple.enfant.prenom!
: couple.enfant.displayName(fallback: 'Enfant'),
fallbackIcon: Icons.child_care,
),
),
),
Container(
width: 8,
height: 44,
decoration: const BoxDecoration(
image: DecorationImage(
image: AssetImage(QuotidienTheme.pencilLineVerticalAsset),
fit: BoxFit.contain,
),
),
),
Expanded(
child: Padding(
padding: const EdgeInsets.only(left: 12),
child: _MembreTile(
photoUrl: couple.am.photoUrl,
name: (couple.am.prenom != null && couple.am.prenom!.isNotEmpty)
? couple.am.prenom!
: couple.am.displayName(
fallback: mode == CoupleBandeauMode.parent
? 'Nounou'
: 'Parent',
),
fallbackIcon: mode == CoupleBandeauMode.parent
? Icons.volunteer_activism
: Icons.person_outline,
),
),
),
SizedBox(
width: 28,
child: showChevron
? const Icon(
Icons.keyboard_arrow_down,
color: QuotidienTheme.ink,
)
: null,
),
],
),
);
}
}
/// Photo ronde + nom (une moitié du couple).
class _MembreTile extends StatelessWidget {
final String? photoUrl;
final String name;
final IconData fallbackIcon;
const _MembreTile({
required this.photoUrl,
required this.name,
required this.fallbackIcon,
});
@override
Widget build(BuildContext context) {
return Row(
children: [
_Avatar(photoUrl: photoUrl, fallbackIcon: fallbackIcon, size: 64),
const SizedBox(width: 12),
Expanded(
child: Text(
name,
maxLines: 1,
overflow: TextOverflow.ellipsis,
style: GoogleFonts.merienda(
fontSize: 22,
fontWeight: FontWeight.bold,
color: QuotidienTheme.ink,
),
),
),
],
);
}
}
class _Avatar extends StatelessWidget {
final String? photoUrl;
final IconData fallbackIcon;
final double size;
const _Avatar({
required this.photoUrl,
required this.fallbackIcon,
required this.size,
});
@override
Widget build(BuildContext context) {
final url = ApiConfig.absoluteMediaUrl(photoUrl);
final placeholder = Container(
width: size,
height: size,
color: QuotidienTheme.lavender.withValues(alpha: 0.35),
child: Icon(fallbackIcon, size: size * 0.5, color: QuotidienTheme.ink),
);
return ClipOval(
child: SizedBox(
width: size,
height: size,
child: url.isEmpty
? placeholder
: AuthNetworkImage(
url: url,
width: size,
height: size,
fit: BoxFit.cover,
errorBuilder: (_, __, ___) => placeholder,
),
),
);
}
}
class _CoupleBandeauSkeleton extends StatelessWidget {
const _CoupleBandeauSkeleton();
@override
Widget build(BuildContext context) {
return Container(
height: 90,
decoration: BoxDecoration(
image: DecorationImage(
image: const AssetImage(QuotidienTheme.bandeauLime), // Un asset existant
fit: BoxFit.fill,
colorFilter: ColorFilter.mode(
Colors.white.withValues(alpha: 0.5),
BlendMode.lighten,
),
),
),
alignment: Alignment.center,
child: const SizedBox(
width: 26,
height: 26,
child: CircularProgressIndicator(strokeWidth: 2),
),
);
}
}
class _CoupleBandeauEmpty extends StatelessWidget {
const _CoupleBandeauEmpty();
@override
Widget build(BuildContext context) {
return Container(
height: 90,
decoration: const BoxDecoration(
image: DecorationImage(
image: AssetImage(QuotidienTheme.bandeauLime), // Un asset existant par défaut
fit: BoxFit.fill,
),
),
padding: const EdgeInsets.symmetric(horizontal: 24),
child: Row(
children: [
const Icon(Icons.info_outline, color: QuotidienTheme.muted),
const SizedBox(width: 12),
Expanded(
child: Text(
'Aucune garde active pour le moment.',
style: GoogleFonts.merriweather(
fontSize: 14,
color: QuotidienTheme.muted,
),
),
),
],
),
);
}
}
class _CoupleBandeauError extends StatelessWidget {
final String message;
final VoidCallback? onRetry;
const _CoupleBandeauError({required this.message, this.onRetry});
@override
Widget build(BuildContext context) {
return Container(
height: 90,
decoration: BoxDecoration(
image: DecorationImage(
image: const AssetImage(QuotidienTheme.bandeauLime), // Un asset existant
fit: BoxFit.fill,
colorFilter: ColorFilter.mode(
QuotidienTheme.coral.withValues(alpha: 0.3),
BlendMode.srcATop,
),
),
),
padding: const EdgeInsets.symmetric(horizontal: 24),
child: Row(
children: [
const Icon(Icons.error_outline, color: QuotidienTheme.ink),
const SizedBox(width: 12),
Expanded(
child: Text(
message,
style: GoogleFonts.merriweather(
fontSize: 13,
color: QuotidienTheme.ink,
),
),
),
if (onRetry != null)
TextButton(
onPressed: onRetry,
child: const Text('Réessayer'),
),
],
),
);
}
}
@@ -0,0 +1,282 @@
import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';
import 'package:google_fonts/google_fonts.dart';
import 'package:p_tits_pas/services/auth_service.dart';
import 'package:p_tits_pas/widgets/image_button.dart';
import 'package:p_tits_pas/widgets/quotidien/quotidien_theme.dart';
/// Bandeau quotidien pastel : logo · pastilles Cahier de liaison / Agenda /
/// Contrat · menu user.
/// Réutilisable parent (#166) et AM (#169).
class QuotidienBandeau extends StatelessWidget {
final QuotidienNavSection selectedSection;
final ValueChanged<QuotidienNavSection> onSectionSelected;
final String userDisplayName;
final String? userEmail;
final VoidCallback? onProfileTap;
final VoidCallback? onSearchAmTap;
final VoidCallback? onSettingsTap;
final VoidCallback? onLogout;
const QuotidienBandeau({
super.key,
required this.selectedSection,
required this.onSectionSelected,
required this.userDisplayName,
this.userEmail,
this.onProfileTap,
this.onSearchAmTap,
this.onSettingsTap,
this.onLogout,
});
@override
Widget build(BuildContext context) {
return Padding(
padding: const EdgeInsets.fromLTRB(16, 12, 16, 8),
child: Row(
children: [
Image.asset(
QuotidienTheme.logoAsset,
height: 44,
fit: BoxFit.contain,
),
const Spacer(),
_NavPills(
selected: selectedSection,
onSelected: onSectionSelected,
),
const Spacer(),
_UserMenu(
displayName: userDisplayName,
email: userEmail,
onProfileTap: onProfileTap,
onSearchAmTap: onSearchAmTap,
onSettingsTap: onSettingsTap,
onLogout: onLogout,
),
],
),
);
}
}
class _NavPills extends StatelessWidget {
final QuotidienNavSection selected;
final ValueChanged<QuotidienNavSection> onSelected;
const _NavPills({
required this.selected,
required this.onSelected,
});
@override
Widget build(BuildContext context) {
return Row(
mainAxisSize: MainAxisSize.min,
children: [
_pill(
label: 'Cahier de liaison',
section: QuotidienNavSection.liaison,
),
const SizedBox(width: 10),
_pill(
label: 'Agenda',
section: QuotidienNavSection.agenda,
),
const SizedBox(width: 10),
_pill(
label: 'Contrat',
section: QuotidienNavSection.contrat,
),
],
);
}
Widget _pill({
required String label,
required QuotidienNavSection section,
}) {
final active = selected == section;
// Même famille que linscription : fonds « dessinés » (pas Material).
// Les deux pastilles ont la même silhouette (ratio ~4:1) : la largeur
// est dérivée de la hauteur pour ne jamais déformer le PNG.
// Chaque section garde sa couleur ; l'inactive est juste plus claire.
return ImageButton(
bg: QuotidienTheme.pillAssetFor(section),
bgOpacity: active ? 1.0 : QuotidienTheme.pillInactiveOpacity,
width: _pillHeight * QuotidienTheme.pillAspectRatio,
height: _pillHeight,
text: label,
textColor: QuotidienTheme.ink,
fontSize: 14,
onPressed: () => onSelected(section),
);
}
static const double _pillHeight = 46;
}
class _UserMenu extends StatelessWidget {
final String displayName;
final String? email;
final VoidCallback? onProfileTap;
final VoidCallback? onSearchAmTap;
final VoidCallback? onSettingsTap;
final VoidCallback? onLogout;
const _UserMenu({
required this.displayName,
this.email,
this.onProfileTap,
this.onSearchAmTap,
this.onSettingsTap,
this.onLogout,
});
@override
Widget build(BuildContext context) {
final shortName = displayName.trim().isEmpty ? 'Compte' : displayName.trim();
const double pillHeight = 46;
const double pillWidth = pillHeight * QuotidienTheme.pillAspectRatio;
return PopupMenuButton<String>(
tooltip: 'Menu utilisateur',
offset: const Offset(0, pillHeight + 4),
color: QuotidienTheme.ivory,
elevation: 3,
shape: RoundedRectangleBorder(
borderRadius: BorderRadius.circular(16),
side: BorderSide(color: QuotidienTheme.lavender.withOpacity(0.6)),
),
onSelected: (value) async {
switch (value) {
case 'profile':
onProfileTap?.call();
break;
case 'search_am':
onSearchAmTap?.call();
break;
case 'settings':
onSettingsTap?.call();
break;
case 'logout':
await _confirmLogout(context);
break;
}
},
itemBuilder: (context) => [
if (email != null && email!.trim().isNotEmpty)
PopupMenuItem(
enabled: false,
child: Text(
email!,
style: TextStyle(color: QuotidienTheme.muted, fontSize: 12),
),
),
const PopupMenuDivider(),
const PopupMenuItem(
value: 'profile',
child: ListTile(
dense: true,
contentPadding: EdgeInsets.zero,
leading: Icon(Icons.person_outline, size: 20),
title: Text('Profil'),
),
),
const PopupMenuItem(
value: 'search_am',
child: ListTile(
dense: true,
contentPadding: EdgeInsets.zero,
leading: Icon(Icons.search, size: 20),
title: Text('Recherche AM'),
),
),
const PopupMenuItem(
value: 'settings',
child: ListTile(
dense: true,
contentPadding: EdgeInsets.zero,
leading: Icon(Icons.settings_outlined, size: 20),
title: Text('Paramètres'),
),
),
const PopupMenuDivider(),
const PopupMenuItem(
value: 'logout',
child: ListTile(
dense: true,
contentPadding: EdgeInsets.zero,
leading: Icon(Icons.logout, size: 20),
title: Text('Déconnexion'),
),
),
],
// Même pastille « dessinée » que la nav, teinte violet pastel charte.
child: Container(
width: pillWidth,
height: pillHeight,
padding: const EdgeInsets.symmetric(horizontal: 14),
decoration: const BoxDecoration(
image: DecorationImage(
image: AssetImage(QuotidienTheme.pillLavenderAsset),
fit: BoxFit.fill,
),
),
child: Row(
children: [
const Icon(
Icons.person_outline,
size: 20,
color: QuotidienTheme.ink,
),
const SizedBox(width: 6),
Expanded(
child: Text(
shortName,
maxLines: 1,
overflow: TextOverflow.ellipsis,
style: GoogleFonts.merienda(
fontSize: 13,
fontWeight: FontWeight.bold,
color: QuotidienTheme.ink,
),
),
),
const Icon(
Icons.keyboard_arrow_down,
size: 18,
color: QuotidienTheme.ink,
),
],
),
),
);
}
Future<void> _confirmLogout(BuildContext context) async {
final ok = await showDialog<bool>(
context: context,
builder: (ctx) => AlertDialog(
title: const Text('Déconnexion'),
content: const Text('Voulez-vous vraiment vous déconnecter ?'),
actions: [
TextButton(
onPressed: () => Navigator.of(ctx).pop(false),
child: const Text('Annuler'),
),
TextButton(
onPressed: () => Navigator.of(ctx).pop(true),
child: const Text('Déconnexion'),
),
],
),
);
if (ok != true) return;
onLogout?.call();
await AuthService.logout();
if (context.mounted) {
context.go('/login');
}
}
}
@@ -0,0 +1,320 @@
import 'package:flutter/material.dart';
import 'package:google_fonts/google_fonts.dart';
import 'package:p_tits_pas/widgets/app_footer.dart';
import 'package:p_tits_pas/widgets/quotidien/quotidien_bandeau.dart';
import 'package:p_tits_pas/widgets/quotidien/quotidien_theme.dart';
/// Coquille « Cahier de liaison » quotidien 3 colonnes + bandeau (#166).
/// LAM (#169) réutilise ce widget en injectant ses slots.
class QuotidienShell extends StatelessWidget {
final QuotidienNavSection selectedSection;
final ValueChanged<QuotidienNavSection> onSectionSelected;
final String userDisplayName;
final String? userEmail;
final VoidCallback? onProfileTap;
final VoidCallback? onSearchAmTap;
final VoidCallback? onSettingsTap;
final VoidCallback? onLogout;
/// Colonne gauche (couple + cartes + actions).
final Widget leftColumn;
/// Colonne milieu (blog).
final Widget centerColumn;
/// Colonne droite (messagerie).
final Widget rightColumn;
/// Corps affiché hors Cahier de liaison (Agenda / Contrat stubs).
final Widget? agendaBody;
final Widget? contratBody;
const QuotidienShell({
super.key,
required this.selectedSection,
required this.onSectionSelected,
required this.userDisplayName,
required this.leftColumn,
required this.centerColumn,
required this.rightColumn,
this.userEmail,
this.onProfileTap,
this.onSearchAmTap,
this.onSettingsTap,
this.onLogout,
this.agendaBody,
this.contratBody,
});
@override
Widget build(BuildContext context) {
return Scaffold(
backgroundColor: QuotidienTheme.ivory,
body: Container(
decoration: QuotidienTheme.paperBackground(),
child: Column(
children: [
QuotidienBandeau(
selectedSection: selectedSection,
onSectionSelected: onSectionSelected,
userDisplayName: userDisplayName,
userEmail: userEmail,
onProfileTap: onProfileTap,
onSearchAmTap: onSearchAmTap,
onSettingsTap: onSettingsTap,
onLogout: onLogout,
),
const QuotidienPencilDivider(),
Expanded(child: _bodyForSection(context)),
const QuotidienPencilDivider(),
const AppFooter(showTopBorder: false),
],
),
),
);
}
Widget _bodyForSection(BuildContext context) {
switch (selectedSection) {
case QuotidienNavSection.liaison:
return _ThreeColumns(
left: leftColumn,
center: centerColumn,
right: rightColumn,
);
case QuotidienNavSection.agenda:
return agendaBody ??
const QuotidienStubPage(
title: 'Agenda',
message: 'Page Agenda — à venir.',
);
case QuotidienNavSection.contrat:
return contratBody ??
const QuotidienStubPage(
title: 'Contrat',
message: 'Page Contrat — à venir.',
);
}
}
}
/// Trait « crayon gris » dessiné à la main : sépare bandeau / corps / footer
/// (horizontal) et les 3 colonnes (vertical). Le PNG (2400×28) est étiré dans
/// le sens du trait seulement : sur un trait, c'est invisible.
class QuotidienPencilDivider extends StatelessWidget {
final Axis axis;
/// Épaisseur de la zone du trait (hauteur si horizontal, largeur sinon).
final double thickness;
final EdgeInsets padding;
const QuotidienPencilDivider({
super.key,
this.axis = Axis.horizontal,
this.thickness = 14,
this.padding = const EdgeInsets.symmetric(horizontal: 24),
});
const QuotidienPencilDivider.vertical({
super.key,
this.thickness = 14,
this.padding = const EdgeInsets.symmetric(vertical: 16),
}) : axis = Axis.vertical;
@override
Widget build(BuildContext context) {
final horizontal = axis == Axis.horizontal;
return Padding(
padding: padding,
child: SizedBox(
width: horizontal ? double.infinity : thickness,
height: horizontal ? thickness : double.infinity,
child: Image.asset(
horizontal
? QuotidienTheme.pencilLineAsset
: QuotidienTheme.pencilLineVerticalAsset,
fit: BoxFit.fill,
filterQuality: FilterQuality.medium,
),
),
);
}
}
class _ThreeColumns extends StatelessWidget {
final Widget left;
final Widget center;
final Widget right;
const _ThreeColumns({
required this.left,
required this.center,
required this.right,
});
@override
Widget build(BuildContext context) {
return LayoutBuilder(
builder: (context, constraints) {
final wide = constraints.maxWidth >= 900;
if (!wide) {
// Socle mobile temporaire (#188 = swipe dédié) : pile verticale.
return ListView(
padding: const EdgeInsets.fromLTRB(12, 4, 12, 12),
children: [
_ColumnPanel(child: left),
const QuotidienPencilDivider(
padding: EdgeInsets.symmetric(horizontal: 32, vertical: 4),
),
_ColumnPanel(child: center),
const QuotidienPencilDivider(
padding: EdgeInsets.symmetric(horizontal: 32, vertical: 4),
),
_ColumnPanel(child: right),
],
);
}
return Padding(
padding: const EdgeInsets.fromLTRB(16, 4, 16, 12),
child: Row(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [
Expanded(child: _ColumnPanel(child: left)),
const QuotidienPencilDivider.vertical(),
Expanded(child: _ColumnPanel(child: center)),
const QuotidienPencilDivider.vertical(),
Expanded(child: _ColumnPanel(child: right)),
],
),
);
},
);
}
}
/// Panneau colonne (carte pastel semi-transparente).
class _ColumnPanel extends StatelessWidget {
final Widget child;
const _ColumnPanel({required this.child});
@override
Widget build(BuildContext context) {
return Container(
// Pas de bordure Material : la séparation est assurée par les traits
// crayon, on garde juste un léger fond.
decoration: BoxDecoration(
color: QuotidienTheme.columnCardFill.withOpacity(0.82),
borderRadius: BorderRadius.circular(16),
),
clipBehavior: Clip.antiAlias,
child: child,
);
}
}
/// Placeholder de colonne métier (branchable par tickets C/D/E).
class QuotidienColumnPlaceholder extends StatelessWidget {
final String title;
final String subtitle;
final IconData icon;
const QuotidienColumnPlaceholder({
super.key,
required this.title,
required this.subtitle,
required this.icon,
});
@override
Widget build(BuildContext context) {
return Padding(
padding: const EdgeInsets.all(20),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [
Row(
children: [
Icon(icon, color: QuotidienTheme.lavender, size: 22),
const SizedBox(width: 8),
Text(
title,
style: GoogleFonts.merienda(
fontSize: 18,
fontWeight: FontWeight.w600,
color: QuotidienTheme.ink,
),
),
],
),
const SizedBox(height: 12),
Expanded(
child: Center(
child: Text(
subtitle,
textAlign: TextAlign.center,
style: GoogleFonts.merriweather(
fontSize: 13,
color: QuotidienTheme.muted,
height: 1.4,
),
),
),
),
],
),
);
}
}
/// Stub pleine page (Agenda / Contrat) — contenu riche hors #166.
class QuotidienStubPage extends StatelessWidget {
final String title;
final String message;
const QuotidienStubPage({
super.key,
required this.title,
required this.message,
});
@override
Widget build(BuildContext context) {
return Center(
child: ConstrainedBox(
constraints: const BoxConstraints(maxWidth: 420),
child: Container(
margin: const EdgeInsets.all(24),
padding: const EdgeInsets.symmetric(horizontal: 28, vertical: 32),
decoration: BoxDecoration(
color: Colors.white.withOpacity(0.85),
borderRadius: BorderRadius.circular(16),
border: Border.all(color: Colors.grey.shade300),
),
child: Column(
mainAxisSize: MainAxisSize.min,
children: [
Text(
title,
style: GoogleFonts.merienda(
fontSize: 22,
fontWeight: FontWeight.w600,
color: QuotidienTheme.ink,
),
),
const SizedBox(height: 12),
Text(
message,
textAlign: TextAlign.center,
style: GoogleFonts.merriweather(
fontSize: 14,
color: QuotidienTheme.muted,
),
),
],
),
),
),
);
}
}
@@ -0,0 +1,90 @@
import 'package:flutter/material.dart';
/// Couleurs / tokens du quotidien parentAM (#166) — lignée papier / pastel.
/// Pas le violet Material du dashboard staff.
abstract final class QuotidienTheme {
static const Color ink = Color(0xFF2F2F2F);
static const Color ivory = Color(0xFFFFFEF9);
static const Color turquoise = Color(0xFF8AD0C8);
static const Color lavender = Color(0xFFC6A3D8);
static const Color coral = Color(0xFFF4A28C);
static const Color softGreenPill = Color(0xFFB8D9A8);
static const Color columnCardFill = Color(0xFFF7F3EA);
static const Color muted = Color(0xFF6B6B6B);
static const String paperAsset = 'assets/images/paper2.png';
static const String logoAsset = 'assets/images/logo.png';
/// Pastilles « dessinées » du bandeau : même silhouette (1190×299), une
/// couleur charte par section ; l'inactive est la même, plus transparente.
static const double pillInactiveOpacity = 0.45;
static const String pillIvoryAsset = 'assets/images/bg_ivoire_pill.png';
static const String pillBlueAsset = 'assets/images/bg_blue_pill.png';
// Bandeaux pour les couples (ratio 10:1, dessinés au crayon, couleur dynamique)
static const String bandeauLime = 'assets/images/bandeau_lime.png';
static const String bandeauBlue = 'assets/images/bandeau_blue.png';
static const String bandeauPeach = 'assets/images/bandeau_peach.png';
static const String bandeauYellow = 'assets/images/bandeau_yellow.png';
static const String bandeauLavender = 'assets/images/bandeau_lavender.png';
static const List<String> bandeauColors = [
bandeauLime,
bandeauBlue,
bandeauPeach,
bandeauYellow,
bandeauLavender,
];
/// Retourne un asset bandeau fixe pour un couple donné (basé sur son ID)
static String bandeauAssetForCouple(String coupleId) {
if (coupleId.isEmpty) return bandeauLime;
final hash = coupleId.hashCode.abs();
return bandeauColors[hash % bandeauColors.length];
}
static const String pillYellowAsset = 'assets/images/bg_yellow_pill.png';
static const String pillPeachAsset = 'assets/images/bg_peach_pill.png';
static const String pillTurquoiseAsset =
'assets/images/bg_turquoise_pill.png';
static const String pillLavenderAsset =
'assets/images/bg_lavender_pill.png';
/// Trait crayon gris (2400×28, transparent) : séparateurs bandeau / corps /
/// footer. Version verticale (28×2400) entre les colonnes.
static const String pencilLineAsset = 'assets/images/pencil_line_grey.png';
static const String pencilLineVerticalAsset =
'assets/images/pencil_line_grey_v.png';
static String pillAssetFor(QuotidienNavSection section) {
switch (section) {
case QuotidienNavSection.liaison:
return pillYellowAsset;
case QuotidienNavSection.agenda:
return pillPeachAsset;
case QuotidienNavSection.contrat:
return pillTurquoiseAsset;
}
}
/// Largeur / hauteur des PNG de pastille, à respecter pour ne pas déformer.
static const double pillAspectRatio = 1190 / 298;
static BoxDecoration paperBackground() {
return const BoxDecoration(
image: DecorationImage(
image: AssetImage(paperAsset),
fit: BoxFit.cover,
repeat: ImageRepeat.repeat,
),
);
}
}
/// Sections du bandeau quotidien (Cahier de liaison / Agenda / Contrat).
/// `liaison` = le hub « Cahier de liaison » (cartes · blog · messagerie).
enum QuotidienNavSection {
liaison,
agenda,
contrat,
}