La création de projet échouait : `Project.workflow` est obligatoire mais
n'était jamais fourni (formulaire frontend, MCP create-project), tout POST
/api/projects partait en erreur de validation/contrainte NOT NULL.
- ProjectDefaultWorkflowListener (prePersist) : assigne le workflow par
défaut quand aucun n'est fourni, couvrant API Platform, API brute et MCP.
- retrait de l'Assert\NotNull sur Project::workflow (la validation tournait
avant le flush et empêchait le filet) ; la contrainte DB reste le garde-fou.
- CreateProjectTool (MCP) : paramètre optionnel workflowId.
- ProjectDrawer : sélecteur Workflow en création, pré-rempli sur le défaut,
IRI envoyée dans le payload.
- tests fonctionnels : création avec et sans workflow.
- ajoute des tests fonctionnels (archive au DELETE, exclusion de la
collection, listing/désarchivage admin, anti-auto-archivage) et un test
unitaire du ArchivedUserChecker
- expose un filtre BooleanFilter `archived` + bypass admin dans
ExcludeArchivedUserExtension pour lister les archivés (?archived=true)
- rend `archived` modifiable par un admin (groupe user:write + ApiProperty
ROLE_ADMIN) → désarchivage possible via PATCH /api/users/{id}
- RestoreMissingUsersCommand : ne compte que les insertions réelles
(ON CONFLICT DO NOTHING n'est plus comptabilisé à tort)
- relève memory_limit des tests à 512M (boot sérialiseur API Platform)
Un user supprimé physiquement laissait des références orphelines (task.assignee,
time entries, notifications) car les FK vers "user" ont été créées NOT VALID lors
du refactor modular-monolith : elles n'ont jamais nettoyé les orphelins legacy. La
sérialisation API Platform d'une tâche embarquant un assignee inexistant levait une
EntityNotFoundException non rattrapable (HTTP 500 sur tout PATCH/GET de ces tickets).
- User::$archived (bool) + migration (soft delete)
- Delete de User -> UserArchiveProcessor : archive (archived=true, apiToken vidé)
au lieu de supprimer, préservant l'intégrité référentielle
- ArchivedUserChecker : login bloqué pour un user archivé (firewalls login + api)
- ExcludeArchivedUserExtension : archivés exclus de GET /api/users (assignation),
les références existantes restent sérialisées normalement
- Commande app:restore-missing-users : recrée (en archivés) les users encore
référencés mais supprimés, restaurant l'intégrité sans perte de données.
Idempotente, option --dry-run. À lancer une fois en prod après déploiement.
Plumbing complementaire des outils MCP ajoutes en 99626b8 :
- declare findBy() sur Address/Contact/CommercialReport RepositoryInterface
(Prestataire l'avait deja) pour exposer la methode au contrat DDD
- bindings explicites des 4 repos dans services.yaml (cohrence avec
Client/Prospect, meme si Symfony auto-alias l'interface vers l'unique
implementation)
Ajoute 20 nouveaux outils MCP pour permettre à Claude (ou tout client MCP) de
remplir un dossier client / prospect / prestataire complet — onglets
Information, Contact, Adresse et Rapport — sans passer par l'UI.
Entités couvertes (CRUD complet, 5 outils chacune) :
- Prestataire : create / update / get / list / delete
- Contact : create / update / get / list / delete
- Address : create / update / get / list / delete
- CommercialReport : create / update / get / list / delete
Détails :
- Contact / Address / CommercialReport doivent être rattachés à exactement
un parent parmi clientId, prospectId, prestataireId (validation côté tool).
- get-client, get-prospect et get-prestataire renvoient désormais un payload
enrichi avec la liste de leurs contacts, adresses et rapports liés : un
seul appel pour reconstruire l'onglet entier.
- Pour CommercialReport, le type (note / call / meeting / email) et la date
occurredAt sont validés ; l'auteur est rempli automatiquement par le
listener existant.
- Sécurité : ROLE_ADMIN aligné sur les autres outils MCP de Directory (pas
de migration vers les permissions RBAC fines pour rester cohérent).
Plumbing :
- Repositories Contact / Address / CommercialReport : ajout de findBy() sur
les interfaces (l'implémentation Doctrine l'a déjà via ServiceEntityRepository).
- Bindings interface -> implémentation Doctrine ajoutés dans services.yaml
pour Prestataire / Contact / Address / CommercialReport.
- Sérialiseur partagé étendu : prestataire / contact / address /
commercialReport / reportDocument.
Vérification : 86 outils MCP exposés au total (66 avant + 20 ajoutés), test
end-to-end via le transport HTTP (create-prestataire + create-contact +
create-address + create-commercial-report + get-prestataire renvoyant le
dossier complet). Suite PHPUnit verte.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Prestataire : entité/repo + ressource API Platform (RBAC directory.providers.*),
ownership prestataire sur contacts/adresses/comptes-rendus (CHECK XOR à 3),
DTO/service/drawer/fiche détail + onglet dédié dans le répertoire.
- Prospect : société uniquement (suppression du champ name, company requis) ;
migration de backfill, conversion prospect→client et MCP adaptés.
- Champ site web sur client/prospect/prestataire (entités, DTO, onglet Information, MCP).
- Validateurs front email / téléphone FR (0549200910) / URL sur Information et Contacts,
enregistrement bloqué tant qu'un champ est invalide.
- Autocomplete adresse branché sur la Base Adresse Nationale (api-adresse.data.gouv.fr)
avec mode dégradé en saisie libre.
- Administration : retrait de l'onglet Clients.
Au passage d'une période de référence, le report de l'"en cours
d'acquisition" (N) vers l'"acquis" (N-1) ne déduisait pas les jours
déjà pris : un salarié récupérait les CP qu'il avait consommés.
Le report ne porte désormais que les jours non pris. Les congés sont
imputés au plus ancien bucket d'abord (l'acquis N-2, qui expire de toute
façon au changement de période), donc seuls les jours pris au-delà
réduisent le report.
Ajoute AccrueLeaveCommandTest couvrant le report avec jour pris,
l'imputation oldest-first et le report intégral sans jour pris.
La revue de sécurité a relevé que les écritures de TimeEntry (Post/Patch/Delete)
étaient gardées par time-tracking.entries.view : une permission de lecture
accordait l'écriture (confusion lecture/écriture, least-privilege).
- Ajout de la permission time-tracking.entries.manage (catalogue cohérent avec
les autres modules en view/manage).
- Écritures TimeEntry recâblées sur entries.manage ; self-service conservé
(object.getUser() == user). Lecture inchangée (entries.view).
Les ressources métier (ProjectManagement, Directory, TimeTracking) étaient
gardées par is_granted('ROLE_USER')/'ROLE_ADMIN', ignorant les permissions
RBAC granulaires déclarées par les modules : un utilisateur sans permission
voyait quand même projets, tâches, clients, etc.
- PermissionVoter : le regex excluait les tirets, donc project-management.* et
time-tracking.* n'étaient supportées par aucun voter (refus pour tous, admin
compris car le bypass ROLE_ADMIN est interne au voter). Ajout du tiret.
- Câblage des permissions *.view (lecture) / *.manage (écriture) sur les 17
ressources métier. Métadonnées tâches lisibles via projects.view OR tasks.view.
Directory partagé client/prospect via clients.* OR prospects.*. TimeEntry
conserve le self-service (object.getUser() == user).
- Sidebar : gating par permission effective des onglets Projets / Mes tâches /
Suivi du temps (config/sidebar.php).
- Test fonctionnel ProjectAccessControlTest (0 perm -> 403, view -> 200,
view ne donne pas l'écriture -> 403).