836f177ff9ffcade42db382c155353b8765b7c3a
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
836f177ff9 | docs(commercial) : migration racine + seed fixture CategoryType (blocages ERP-53 vérifiés) | ||
|
|
1d91b4dea9 |
docs(commercial) : fix § 3.5 incohérence AuditIgnore RIB (aligné sur § 2.5)
Auto Tag Develop / tag (push) Failing after 30s
|
||
|
|
2866fb8865 |
[docs] M1 — Répertoire clients : specs front + back (#23)
Auto Tag Develop / tag (push) Successful in 36s
## Contexte Spécifications front + back du **Module 1 — Répertoire clients** (premier module métier Tiers, extension du module `Commercial` existant). Origine : V0 client `.docx` du 22/05/2026 (`M1-reportoire-clients.docx`) + maquette Figma `https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-31898`. Pattern de rédaction : strictement aligné sur `docs/specs/M0-categories/` (spec-front léger + spec-back très détaillé). ## Contenu - `docs/specs/M1-clients/spec-front.md` (289 lignes) — V0 client, structure UI, composants Malio, permissions par rôle, règles de formatage - `docs/specs/M1-clients/spec-back.md` (1056 lignes) — décisions archi, modèle données, migration SQL Postgres, API REST, RBAC matrice complète, 27 RG numérotées, tests à automatiser, 16 HP, liens & dépendances ## Décisions structurantes (validées avec Tristan le 28/05/2026) - **Module** : extension de `Commercial/` (pas nouveau module) - **Catégories Client** : M2M `client_category` + seed `CategoryType` (`DISTRIBUTEUR`, `COURTIER`, `SECTEUR`, `AUTRE`) - **Distributeur / Courtier** : 2 FK auto-référentes nullables sur `client` + contrainte CHECK mutex - **Workflow création** : sauvegarde incrémentale par onglet (POST formulaire principal → PATCH par onglet) - **Onglets « À venir »** (Transport / Statistiques / Rapports / Échanges) : placeholders blancs (frames vides, pas de message texte) - **Archive vs delete** : flag `is_archived` exposé au M1, colonne `deleted_at` préparée mais non exposée (HP M2) - **API adresse** : api-adresse.data.gouv.fr (BAN), appel direct front via `useAddressAutocomplete()` - **Unicité métier** : SIREN + `companyName` + email (indexes partiels Postgres, ignorent archivés et soft-deletés) - **Téléphones** : 2 colonnes plates `phone_primary` + `phone_secondary` - **Export** : XLSX uniquement (controller custom avec `priority: 1`) - **Compta = lecture seule** ⚠ s'écarte du tableau du `.docx` (ligne « Compta = Ajout/Modification Comptabilité uniquement » invalidée) — documenté en HP-M2-10 ## Seed M1 (référentiels comptables) | Référentiel | Valeurs | |---|---| | `tva_mode` | `FRANCE_VENTES`, `EXPORT_VENTES`, `INTRACOM_VENTES` | | `payment_delay` | `J15`, `J30`, `A_RECEPTION` | | `payment_type` | `VIREMENT`, `LCR`, `NON_SOUMISE`, `CHEQUE` | | `bank` | `SG`, `CIC`, `CA` (Société Générale / CIC / Crédit Agricole) | | `category_type` (extension M0) | `DISTRIBUTEUR`, `COURTIER`, `SECTEUR`, `AUTRE` | ## RG ajoutées au-delà du `.docx` - **RG-1.14** : ≥ 1 bloc Contact valide obligatoire (renforcement Tristan) - **RG-1.15/16/17** : unicités SIREN / nom / email - **RG-1.18** : `companyName` UPPERCASE serveur - **RG-1.19** : `firstName` / `lastName` Capitalize serveur - **RG-1.20** : téléphones chiffres seuls en BDD, formatage `XX XX XX XX XX` au front - **RG-1.21** : emails lowercase serveur - **RG-1.22/23** : archivage / restauration + conflit unicité à la restauration ## Permissions RBAC (à synchroniser dans les 3 miroirs au moment du dev) | Permission | Admin | Bureau | Compta | Commerciale | Usine | |---|---|---|---|---|---| | `commercial.clients.view` | ✅ | ✅ | ✅ | ✅ | ❌ | | `commercial.clients.manage` | ✅ | ✅ | ❌ | ✅ | ❌ | | `commercial.clients.accounting.view` | ✅ | ❌ | ✅ | ❌ | ❌ | | `commercial.clients.accounting.manage` | ✅ | ❌ | ❌ | ❌ | ❌ | | `commercial.clients.archive` | ✅ | ❌ | ❌ | ❌ | ❌ | ## Prochaines étapes (hors MR) 1. Revue / validation des specs par Matthieu 2. Création du **TaskGroup Lesstime** `M1 — Répertoire clients` (projet `ERP / Starseed`, projectId=6) 3. Découpage en ~14 tickets (ordre indicatif listé en bas du `spec-back.md`) ## Reviewer suggéré Matthieu (CP MALIO). ## Cible `develop`. --------- Co-authored-by: admin malio <malio@yuno.malio.fr> Co-authored-by: Matthieu <mtholot19@gmail.com> Reviewed-on: #23 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> |
||
|
|
6efe7aa8ea |
[ERP-52] Créer le pattern Timestampable + Blamable Shared (#13)
Auto Tag Develop / tag (push) Successful in 9s
## Contexte Ticket Lesstime : [#52](https://project.malio-dev.fr/projects/6/tasks/463) Position dans le groupe M0 : 0.0 (prérequis transverse) ## Implémentation - 2 interfaces (`TimestampableInterface`, `BlamableInterface`) dans `Shared/Domain/Contract/` - 1 trait (`TimestampableBlamableTrait`) dans `Shared/Domain/Trait/` - 1 Subscriber Doctrine (`TimestampableBlamableSubscriber`) dans `Shared/Infrastructure/Doctrine/` - 1 ligne `resolve_target_entities` ajoutée à `config/packages/doctrine.yaml` (`UserInterface` → `User`) - 1 test architecture (`EntitiesAreTimestampableBlamableTest`) garde-fou L3 de la spec § 2.8.bis - 1 test unitaire (`TimestampableBlamableSubscriberTest`) 4 cas ## Décision EXCLUDED (cf. réponse review) Les 4 entités préexistantes (`User`, `Role`, `Permission`, `Site`) sont **whitelistées** dans `EXCLUDED` avec justification par entrée, plutôt que rétrofitées dans ce ticket. Le rétrofit de `User` et `Site` est documenté en **HP-9 / HP-10** (récursion Blamable + migration → décision archi scopée). Doc mise à jour : spec § 2.8.bis, § 9, et `.claude/rules/backend.md`. ## Tests - PHPUnit : 5 nouveaux tests, 0 échec, 0 risky (248 tests / 874 assertions au total) - php-cs-fixer : OK ## Reviewer suggéré - Tristan --------- Co-authored-by: Matthieu <mtholot19@gmail.com> Reviewed-on: #13 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> |
||
|
|
5db644d22e |
docs(catalog) : M0 categories specs (back + front) (#12)
Auto Tag Develop / tag (push) Successful in 10s
## Contexte Premier passage du workflow MALIO sur un module concret. Cette MR introduit **uniquement la documentation** (2 specs Markdown) du **Module 0 — Gestion des catégories**. Aucun code applicatif n'est touché. La spec back a été cadrée sur l'archi DDD réelle de Starseed (cf. `.claude/rules/architecture.md` + `backend.md`) après audit du repo (modules `Core`, `Commercial`, `Sites`). Elle introduit aussi un **nouveau module `Catalog`** (bounded context "référentiels partagés") — non créé dans cette MR, il viendra avec les tickets de dev. ## Contenu | Fichier | Lignes | Objet | |---|---|---| | `docs/specs/M0-categories/spec-back.md` | 700 | Spec back v1.1 : modèle data, API REST (5 endpoints + CategoryType lecture seule), 13 RG (RG-1.01 → RG-1.13), validation, autorisation, audit, tests, hors-périmètre | | `docs/specs/M0-categories/spec-front.md` | 113 | Spec front V0 client (validée 2026-05-22) : UI admin (datatable + drawer), 2 champs (Nom + Type), 3 actions (Ajouter / Consulter / Modifier), permissions par rôle | ## Décisions d'archi (auto-validation back-only) Toutes les décisions sont documentées dans `spec-back.md § 2` : - **Module `Catalog`** créé séparément de `Commercial` pour rester réutilisable par les futurs modules Tiers (M-Clients, M-Fournisseurs, M-Prestas) - **IDs INT IDENTITY** (cohérent avec `User`, `Role`, etc.) - **Soft delete** via `deleted_at TIMESTAMP(0) WITHOUT TIME ZONE NULL` — *pattern introduit par ce module* (aucune autre entité Starseed ne le portait) - **Index unique partiel Postgres** sur `(LOWER(name), category_type_id) WHERE deleted_at IS NULL` → unicité case-insensitive parmi non soft-deleted, recréation possible après suppression logique - **Granularité permissions = `view` + `manage`** (aligné sur `core.users.view` + `core.users.manage`) - **Référentiel `CategoryType`** = entité séparée, table vide à la livraison, valeurs seedées plus tard (HP-1) ## Règles métier (RG-1.01 → RG-1.13) Chaque RG est numérotée, stable, testable, et constituera un critère d'acceptation côté ticket Lesstime (cf. `spec-back.md § 7`). Couverture par catégorie : - Autorisation : RG-1.01 (Admin only) - Champ `name` : RG-1.02 (obligatoire), RG-1.03 (trim), RG-1.04 (longueur 2-120) - Champ `categoryType` : RG-1.05 (obligatoire), RG-1.06 (référence valide) - Unicité : RG-1.07 (case-insensitive sur couple, hors soft-deleted) - Liste : RG-1.08 (exclut soft-deleted), RG-1.09 (flag `?includeDeleted=true`), RG-1.10 (tri `name ASC`) - Détail : RG-1.11 (404 si soft-deleted) - Suppression : RG-1.12 (soft delete), RG-1.13 (`deletedAt` non modifiable via PATCH) ## Découpe en tickets Lesstime TaskGroup `#22 — M0 — Gestion des catégories` créé sur le projet **STARSEED**. 9 tickets en backlog : | # | Ticket Lesstime | Effort | Tag | |---|---|---|---| | 0.1 | `#43` Migrer les tables Category et CategoryType | S | Backend | | 0.2 | `#44` Créer les entités Category et CategoryType | M | Backend | | 0.3 | `#45` Implémenter Provider et Processor Category | M | Backend | | 0.4 | `#46` Exposer le référentiel CategoryType en lecture seule | S | Backend | | 0.5 | `#47` Déclarer le module Catalog et synchroniser RBAC | S | Backend | | 0.6 | `#48` Écrire les tests PHPUnit RG-1.01 à RG-1.13 | M | Backend | | 0.7 | `#49` Créer la page Gestion des catégories (datatable + drawer) | L | Frontend | | 0.8 | `#50` Implémenter les composables useCategoriesAdmin et useCategoryForm | M | Frontend | | 0.9 | `#51` Écrire les tests Vitest des composables Catalog | S | Frontend | **Total estimé** : ~15-25h (9 mini-MR de 1-4h). ## Hors-périmètre (HP) Pas codés / pas inclus dans cette spec (cf. `spec-back.md § 9`) : - HP-1 : CRUD du référentiel `CategoryType` (spec dédiée à venir) - HP-2 : Référencement par les Tiers (les FK `category_id` sur Clients/Fournisseurs/Prestas viendront avec leurs modules) - HP-3 : Restauration d'une catégorie soft-deleted - HP-4 : Hard delete - HP-5 : i18n du `name` - HP-6 : Recherche serveur / filtres avancés - HP-7 : Catégories hiérarchiques (parent / enfant) - HP-8 : Seed des rôles métier Bureau / Compta / Commerciale / Usine ## Checklist review Pas de code → review légère, lecture des 2 `.md` suffit. - [ ] Frontmatter YAML cohérent (module, version, dates, validation client, taskgroup, tags) - [ ] Décisions d'archi argumentées (`spec-back.md § 2`) - [ ] Modèle data réaliste (SQL Postgres rédigé directement, pas de pseudo-code) - [ ] API REST complète (codes HTTP succès + erreurs, payloads, exemples) - [ ] RG numérotées et testables (un humain peut écrire un test PHPUnit à partir de chaque RG sans réinventer) - [ ] Mapping rôles MALIO ↔ permissions RBAC clair (cohérent avec règle ABSOLUE n°8 — 3 sources à toucher) - [ ] Hors-périmètre explicite ## Stratégie de merge **Squash merge** vers `develop` (1 PR = 1 commit propre dans l'historique). ## Lien Lesstime - TaskGroup : `#22 — M0 — Gestion des catégories` (projet ERP / Starseed) - Tickets en backlog : `#43` → `#51` > ⚠️ **À faire manuellement après merge** dans l'UI Lesstime : rattacher les 9 tickets au groupe #22 et leur poser leur effort + tag + priorité (bug typing MCP empêche le wire automatique sur des champs `integer` sans `type` explicite dans le schéma). --------- Co-authored-by: Matthieu Tholot <mtholot19@gmail.com> Reviewed-on: #12 Reviewed-by: Autin <tristan@yuno.malio.fr> Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> |