matthieu
8313c759c6
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
77 lines
3.0 KiB
Vue
77 lines
3.0 KiB
Vue
<template>
|
|
<div>
|
|
<div class="sticky top-8 z-20 bg-white pb-4 sm:top-12">
|
|
<h1 class="text-xl font-bold text-primary-500 sm:text-2xl">Administration</h1>
|
|
|
|
<div class="mt-6 border-b border-neutral-200 overflow-x-auto">
|
|
<nav class="flex gap-4 sm:gap-6">
|
|
<button
|
|
v-for="tab in visibleTabs"
|
|
:key="tab.key"
|
|
class="whitespace-nowrap px-1 pb-3 text-sm font-semibold transition"
|
|
:class="activeTab === tab.key
|
|
? 'border-b-2 border-primary-500 text-primary-500'
|
|
: 'text-neutral-500 hover:text-neutral-700'"
|
|
@click="activeTab = tab.key"
|
|
>
|
|
{{ tab.label }}
|
|
</button>
|
|
</nav>
|
|
</div>
|
|
</div>
|
|
|
|
<div>
|
|
<AdminClientTab v-if="activeTab === 'clients'" />
|
|
<AdminWorkflowTab v-if="activeTab === 'workflows'" />
|
|
<AdminEffortTab v-if="activeTab === 'efforts'" />
|
|
<AdminPriorityTab v-if="activeTab === 'priorities'" />
|
|
<AdminTagTab v-if="activeTab === 'tags'" />
|
|
<AdminUserTab v-if="activeTab === 'users'" />
|
|
<AdminRoleTab v-if="activeTab === 'roles' && canViewRoles" />
|
|
<AdminAuditTab v-if="activeTab === 'audit' && canViewAudit" />
|
|
<AdminGiteaTab v-if="activeTab === 'gitea'" />
|
|
<AdminBookStackTab v-if="activeTab === 'bookstack'" />
|
|
<AdminZimbraTab v-if="activeTab === 'zimbra'" />
|
|
<AdminShareTab v-if="activeTab === 'share'" />
|
|
<AdminMailTab v-if="activeTab === 'mail'" />
|
|
<AdminAbsencePolicyTab v-if="activeTab === 'absences'" />
|
|
</div>
|
|
</div>
|
|
</template>
|
|
|
|
<script setup lang="ts">
|
|
definePageMeta({ middleware: ['admin'] })
|
|
useHead({ title: 'Administration' })
|
|
|
|
const { can } = usePermissions()
|
|
const { t } = useI18n()
|
|
|
|
const canViewRoles = computed(() => can('core.roles.view'))
|
|
const canViewAudit = computed(() => can('core.audit_log.view'))
|
|
|
|
const tabs = [
|
|
{ key: 'clients', label: 'Clients' },
|
|
{ key: 'workflows', label: 'Workflows' },
|
|
{ key: 'efforts', label: 'Efforts' },
|
|
{ key: 'priorities', label: 'Priorités' },
|
|
{ key: 'tags', label: 'Tags' },
|
|
{ key: 'users', label: 'Utilisateurs' },
|
|
{ key: 'roles', label: t('admin.roles.title'), permission: 'core.roles.view' },
|
|
{ key: 'audit', label: t('admin.audit.title'), permission: 'core.audit_log.view' },
|
|
{ key: 'gitea', label: 'Gitea' },
|
|
{ key: 'bookstack', label: 'BookStack' },
|
|
{ key: 'zimbra', label: 'Zimbra' },
|
|
{ key: 'share', label: 'Partage' },
|
|
{ key: 'mail', label: 'Mail' },
|
|
{ key: 'absences', label: 'Absences' },
|
|
] as const
|
|
|
|
type TabKey = typeof tabs[number]['key']
|
|
|
|
const visibleTabs = computed(() =>
|
|
tabs.filter((tab) => !('permission' in tab) || can(tab.permission)),
|
|
)
|
|
|
|
const activeTab = ref<TabKey>('clients')
|
|
</script>
|