aad949c10cb26abc63445c374def64b44d84ffec
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 matthieu
|
ad029f5c7d |
chore(directory) : ferme contrats Repository (findBy) + bindings DI MCP Directory
Plumbing complementaire des outils MCP ajoutes en
|
||
|
matthieu
|
99626b89da |
feat(mcp) : outils MCP Directory pour prestataires, contacts, adresses et rapports
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> |
||
 Matthieu
|
5764d8f472 |
feat(directory) : type prestataire, validateurs front, autocomplete adresse BAN
- 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. |
||
|
Matthieu
|
cf3d11a8a3 |
fix(absence) : déduire les jours pris du report CP au changement de période
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. |
||
|
Matthieu
|
4a7fd46493 |
fix(rbac) : add dedicated time-tracking.entries.manage permission
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). |
||
|
Matthieu
|
9705b335ef |
fix(rbac) : enforce granular permissions on business resources
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).
|
||
|
matthieu
|
8313c759c6 |
Migration modular monolith DDD (0.1 → 3.3) (#17)
Auto Tag Develop / tag (push) Successful in 9s
## Migration modular monolith DDD — Lesstime (0.1 → 3.3) Cette MR regroupe l'intégralité de la refonte en monolithe modulaire (strangler progressif, additif). Elle remplace les MR stackées de Phase 1 (#12–#16), désormais incluses ici. **Ne pas merger avant validation fonctionnelle** : branche destinée à être testée telle quelle. ### Périmètre — 9 modules sous `src/Module/` | Phase | Module | Contenu | |------|--------|---------| | 0.1 | (socle) | infrastructure modulaire, `ModuleInterface`, mapping Doctrine par module | | 0.2 | (socle front) | auto-détection des layers Nuxt sous `frontend/modules/*` | | 1.1 | **Core** | Identité (User/Auth), Notifications, Notifier | | 1.2 | Core | RBAC fin (permissions `module.resource.action`, sidebar gated) | | 1.3 | Core | Audit log (`#[Auditable]`, listener, provider DBAL) | | 2.1 | **TimeTracking** | TimeEntry + MCP + export | | 2.2 | **ProjectManagement** | cœur métier Projets/Tâches + 38 MCP tools | | 2.3 | **Absence** | demandes, soldes, policies, justificatifs | | 2.4 | **Directory** | Clients (migrés) + **Prospects** (nouveau, conversion → Client) | | 2.5 | **Mail** | intégration IMAP OVH + liens tâches | | 2.6 | **Integration** | Gitea / BookStack / Zimbra / Share | | 3.1 | **Reporting** | rapports transverses (DBAL read-only, 0 import inter-module) | | 3.2 | **ClientPortal** | portail client (ROLE_CLIENT cloisonné, tickets, notifications) | | 3.3 | (finition) | nettoyage legacy — `src/Entity` vide, app 100% modulaire | ### Architecture - Découplage inter-modules par **contrats** (`UserInterface`, `ProjectInterface`, `TaskInterface`, `TaskTagInterface`, `ClientInterface`, `ClientTicketInterface`, `LeaveProfileInterface`) + `resolve_target_entities` 100% modulaire (aucune cible legacy). - Repositories : interface `Domain/Repository` + implémentation `Infrastructure/Doctrine`, bindées. - Reporting en DBAL read-only pur (aucun import d'entité d'un autre module). - Chaque migration de module : déplacement à comportement préservé (API publique et noms d'outils MCP inchangés), migrations **additives** uniquement (zéro destructif). ### Sécurité - ROLE_CLIENT cloisonné : un utilisateur client n'accède qu'à `/portal` et à ses propres tickets (filtrés par `allowedProjects`), interdit sur toute l'API interne. - Correctif : interdiction pour un client de créer un lien vers le partage SMB (upload uniquement). ### QA non-régression (branche reconstruite from scratch) - Migrations from scratch + fixtures : OK. - Compilation dev + prod : OK. - **180 tests PHPUnit verts**, php-cs-fixer clean, ~96 routes, **66 outils MCP** tous sous `App\Module\*`. - Smoke test runtime multi-rôles (admin / ROLE_USER / ROLE_CLIENT) : 44 vérifications HTTP, **0 écart**, cloisonnement client étanche. - Build Nuxt OK, 9 layers, 0 import legacy résiduel. ### Points à arbitrer (hors périmètre de cette migration) - Durcissement MCP/IDOR pré-existant (`userId` explicite sans scoping sur certains tools TimeTracking/Absence/TaskDocument) — ticket dédié recommandé. - Validation fonctionnelle de **Prospect** et **ClientPortal** (conçus depuis les specs disque). - **Harmonisation visuelle Malio finale** (3.3) — finition esthétique inter-modules laissée au PO. --- ## ⚠️ Déploiement / migration des données — à ne pas oublier ### 1. Resynchroniser les séquences PostgreSQL après tout import/restore de dump Si la prod (ou tout environnement) est **montée depuis un dump** (`pg_restore` / `COPY`), les lignes sont chargées avec leurs `id` explicites **sans avancer les séquences** → au premier `INSERT` : `duplicate key value violates unique constraint "..._pkey"` (constaté en local sur `notification`, `task`, `time_entry`…). À lancer **juste après chaque restore/import** : ```sql DO $$ DECLARE r RECORD; maxid BIGINT; seq TEXT; BEGIN FOR r IN SELECT table_name, column_name FROM information_schema.columns WHERE table_schema='public' LOOP seq := pg_get_serial_sequence(quote_ident(r.table_name), r.column_name); IF seq IS NOT NULL THEN EXECUTE format('SELECT COALESCE(MAX(%I),0) FROM %I', r.column_name, r.table_name) INTO maxid; PERFORM setval(seq, GREATEST(maxid,1), maxid > 0); END IF; END LOOP; END $$; ``` > Ne concerne **pas** une prod qui tourne déjà (séquences avancées organiquement) — uniquement le cas restore/import. Idempotent, sans risque. ### 2. Fix dénormalisation des collections typées-contrat (code, inclus dans la branche) Les relations **to-many** typées par une interface `Shared\Domain\Contract\*` (`TimeEntry::tags` → `TaskTagInterface`, `Task::collaborators` → `UserInterface`) étaient **indénormalisables par API Platform** (mono-valué OK via IRI, collection KO) → **tout POST/PATCH portant une telle collection renvoyait 400/500**. Corrigé par un dénormaliseur générique `ContractRelationDenormalizer` (réutilise `resolve_target_entities`, zéro couplage par-entité) + test fonctionnel de non-régression. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #17 |