diff --git a/.DS_Store b/.DS_Store
index 60b378a6..354e791a 100644
Binary files a/.DS_Store and b/.DS_Store differ
diff --git a/ACTION_PLAN_LOGIN_FLOW.md b/ACTION_PLAN_LOGIN_FLOW.md
deleted file mode 100644
index 7c93d3bc..00000000
--- a/ACTION_PLAN_LOGIN_FLOW.md
+++ /dev/null
@@ -1,425 +0,0 @@
-# Plan d'Action - Amélioration Flow de Connexion
-
-## 🎯 Objectifs
-
-1. **Améliorer l'UX** : Permettre SSO naturel pour les utilisateurs légitimes
-2. **Sécuriser le logout** : S'assurer que les credentials sont demandés après logout
-3. **Simplifier le code** : Réduire la complexité de détection session invalide
-4. **Éliminer les race conditions** : Mécanisme robuste pour éviter auto-login après logout
-
----
-
-## 📋 Actions Immédiates (À faire en premier)
-
-### Action 1 : Supprimer `prompt=login` par défaut ⚡
-
-**Fichier** : `app/api/auth/options.ts`
-
-**Changement** :
-```typescript
-// AVANT (ligne 147-155)
-authorization: {
- params: {
- scope: "openid profile email roles",
- prompt: "login" // ❌ Supprimer cette ligne
- }
-}
-
-// APRÈS
-authorization: {
- params: {
- scope: "openid profile email roles",
- // prompt: "login" supprimé - sera ajouté conditionnellement après logout
- }
-}
-```
-
-**Impact** : ✅ SSO fonctionne naturellement pour les utilisateurs légitimes
-
----
-
-### Action 2 : Créer route API pour marquer logout ⚡
-
-**Nouveau fichier** : `app/api/auth/mark-logout/route.ts`
-
-```typescript
-import { NextRequest, NextResponse } from 'next/server';
-
-export async function POST(request: NextRequest) {
- const response = NextResponse.json({
- success: true,
- message: 'Logout marked successfully'
- });
-
- // Cookie HttpOnly pour marquer le logout (5 minutes)
- response.cookies.set('force_login_prompt', 'true', {
- httpOnly: true,
- secure: process.env.NODE_ENV === 'production',
- sameSite: 'lax',
- path: '/',
- maxAge: 300 // 5 minutes
- });
-
- return response;
-}
-```
-
-**Impact** : ✅ Mécanisme robuste pour forcer login après logout
-
----
-
-### Action 3 : Modifier signout-handler pour utiliser la route ⚡
-
-**Fichier** : `components/auth/signout-handler.tsx`
-
-**Changement** (après ligne 25) :
-```typescript
-// AVANT
-clearKeycloakCookies();
-
-// APRÈS
-clearKeycloakCookies();
-
-// Marquer le logout côté serveur
-try {
- await fetch('/api/auth/mark-logout', {
- method: 'POST',
- credentials: 'include',
- });
-} catch (error) {
- console.error('Error marking logout:', error);
- // Continue même si ça échoue
-}
-```
-
-**Répéter dans** :
-- `components/main-nav.tsx` (ligne ~377)
-- `components/layout/layout-wrapper.tsx` (ligne ~42)
-
-**Impact** : ✅ Flag serveur pour empêcher auto-login
-
----
-
-### Action 4 : Simplifier signin/page.tsx ⚡
-
-**Fichier** : `app/signin/page.tsx`
-
-**Changement** : Remplacer la logique complexe (lignes 17-67) par :
-
-```typescript
-useEffect(() => {
- // Vérifier le cookie serveur pour forcer login
- const forceLoginCookie = document.cookie
- .split(';')
- .find(c => c.trim().startsWith('force_login_prompt='));
-
- // Si logout récent, forcer prompt=login
- if (forceLoginCookie) {
- // Supprimer le cookie
- document.cookie = 'force_login_prompt=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;';
-
- // Ne pas auto-login, attendre clic utilisateur
- // Le bouton "Se connecter" forcera prompt=login
- return;
- }
-
- // Si déjà authentifié, rediriger
- if (status === "authenticated" && session?.user) {
- router.push("/");
- return;
- }
-
- // Si non authentifié et pas de flag logout, auto-login (SSO naturel)
- if (status === "unauthenticated" && !forceLoginCookie) {
- const timer = setTimeout(() => {
- if (status === "unauthenticated") {
- signIn("keycloak", { callbackUrl: "/" });
- }
- }, 1000);
- return () => clearTimeout(timer);
- }
-}, [status, session, router]);
-```
-
-**ET** modifier le bouton "Se connecter" (ligne ~202) :
-
-```typescript
-
-```
-
-**Impact** : ✅ Code plus simple et maintenable
-
----
-
-### Action 5 : Ajouter prompt=login conditionnel dans options.ts ⚡
-
-**Fichier** : `app/api/auth/options.ts`
-
-**Changement** : Modifier la configuration KeycloakProvider pour accepter un paramètre custom :
-
-```typescript
-KeycloakProvider({
- clientId: getRequiredEnvVar("KEYCLOAK_CLIENT_ID"),
- clientSecret: getRequiredEnvVar("KEYCLOAK_CLIENT_SECRET"),
- issuer: getRequiredEnvVar("KEYCLOAK_ISSUER"),
- authorization: {
- params: {
- scope: "openid profile email roles",
- // prompt sera ajouté dynamiquement si force_login=true dans l'URL
- }
- },
- // ... profile callback ...
-})
-```
-
-**ET** créer une route custom pour signin qui ajoute prompt :
-
-**Nouveau fichier** : `app/api/auth/signin/keycloak/route.ts`
-
-```typescript
-import { NextRequest, NextResponse } from 'next/server';
-import { getServerSession } from 'next-auth/next';
-import { authOptions } from '../../options';
-
-export async function GET(request: NextRequest) {
- const searchParams = request.nextUrl.searchParams;
- const forceLogin = searchParams.get('force_login') === 'true';
- const callbackUrl = searchParams.get('callbackUrl') || '/';
-
- // Rediriger vers NextAuth signin avec prompt si nécessaire
- const signinUrl = new URL('/api/auth/signin/keycloak', request.nextUrl.origin);
- signinUrl.searchParams.set('callbackUrl', callbackUrl);
-
- if (forceLogin) {
- // Ajouter prompt=login dans l'URL de redirection Keycloak
- // Note: NextAuth ne supporte pas directement, il faut modifier l'URL après
- // Solution alternative: Utiliser un middleware ou modifier options dynamiquement
- }
-
- return NextResponse.redirect(signinUrl);
-}
-```
-
-**OU** Solution plus simple : Modifier directement dans `options.ts` pour lire un cookie :
-
-```typescript
-// Dans options.ts, modifier authorization params dynamiquement
-authorization: {
- params: (provider, action, request) => {
- const forceLogin = request?.cookies?.get('force_login_prompt')?.value === 'true';
- return {
- scope: "openid profile email roles",
- ...(forceLogin ? { prompt: "login" } : {}),
- };
- }
-}
-```
-
-**Note** : NextAuth v4 ne supporte pas `params` comme fonction. Solution alternative :
-
-**Modifier** `app/api/auth/options.ts` pour utiliser `authorization.url` :
-
-```typescript
-KeycloakProvider({
- // ... config ...
- authorization: {
- params: {
- scope: "openid profile email roles",
- },
- // Ajouter prompt dynamiquement via URL personnalisée
- url: (params) => {
- // Vérifier si on doit forcer login (via cookie ou autre moyen)
- const url = new URL(`${process.env.KEYCLOAK_ISSUER}/protocol/openid-connect/auth`);
- url.searchParams.set('client_id', process.env.KEYCLOAK_CLIENT_ID!);
- url.searchParams.set('redirect_uri', params.redirect_uri);
- url.searchParams.set('response_type', 'code');
- url.searchParams.set('scope', 'openid profile email roles');
- url.searchParams.set('state', params.state);
-
- // Ajouter prompt si nécessaire (à vérifier via cookie dans le callback)
- // Note: Plus complexe, nécessite de passer le flag via state
- return url.toString();
- }
- }
-})
-```
-
-**Solution RECOMMANDÉE (plus simple)** : Utiliser un paramètre dans l'URL de callback et le vérifier dans le callback JWT :
-
-```typescript
-// Dans signin/page.tsx, lors du clic sur "Se connecter"
-const url = new URL(window.location.origin + '/api/auth/signin/keycloak');
-url.searchParams.set('callbackUrl', '/');
-url.searchParams.set('force_login', 'true');
-// Stocker dans sessionStorage pour le callback
-sessionStorage.setItem('force_login', 'true');
-window.location.href = url.toString();
-
-// Dans options.ts, callback jwt, vérifier sessionStorage n'est pas possible côté serveur
-// Solution: Passer via state OAuth
-```
-
-**MEILLEURE SOLUTION** : Utiliser un cookie avant le signIn :
-
-```typescript
-// Dans signin/page.tsx, bouton "Se connecter"
-onClick={() => {
- // Créer cookie pour forcer login
- document.cookie = 'force_login_prompt=true; path=/; max-age=300';
- // Puis signIn normal
- signIn("keycloak", { callbackUrl: "/" });
-}}
-
-// Dans options.ts, lire le cookie dans authorization params
-// Note: NextAuth ne permet pas d'accéder aux cookies dans params
-// Solution: Middleware ou route custom
-```
-
-**SOLUTION FINALE RECOMMANDÉE** : Créer une route API custom qui gère le signin avec prompt conditionnel :
-
-```typescript
-// app/api/auth/custom-signin/route.ts
-import { NextRequest, NextResponse } from 'next/server';
-
-export async function GET(request: NextRequest) {
- const searchParams = request.nextUrl.searchParams;
- const forceLogin = searchParams.get('force_login') === 'true';
- const callbackUrl = searchParams.get('callbackUrl') || '/';
-
- // Construire l'URL Keycloak avec prompt si nécessaire
- const keycloakIssuer = process.env.KEYCLOAK_ISSUER!;
- const clientId = process.env.KEYCLOAK_CLIENT_ID!;
- const redirectUri = `${request.nextUrl.origin}/api/auth/callback/keycloak`;
-
- const authUrl = new URL(`${keycloakIssuer}/protocol/openid-connect/auth`);
- authUrl.searchParams.set('client_id', clientId);
- authUrl.searchParams.set('redirect_uri', redirectUri);
- authUrl.searchParams.set('response_type', 'code');
- authUrl.searchParams.set('scope', 'openid profile email roles');
- authUrl.searchParams.set('state', generateState()); // Générer state
-
- if (forceLogin) {
- authUrl.searchParams.set('prompt', 'login');
- }
-
- return NextResponse.redirect(authUrl.toString());
-}
-```
-
-**Impact** : ✅ Prompt login seulement après logout
-
----
-
-## 🔧 Actions Secondaires (Après les actions immédiates)
-
-### Action 6 : Configurer explicitement les cookies NextAuth
-
-**Fichier** : `app/api/auth/options.ts`
-
-**Ajouter** après `session: { ... }` :
-
-```typescript
-cookies: {
- sessionToken: {
- name: `next-auth.session-token`,
- options: {
- httpOnly: true,
- sameSite: 'lax',
- path: '/',
- secure: process.env.NEXTAUTH_URL?.startsWith('https://') ?? false,
- },
- },
- // ... autres cookies si nécessaire
-},
-```
-
----
-
-### Action 7 : Améliorer Keycloak logout URL
-
-**Fichiers** :
-- `components/auth/signout-handler.tsx`
-- `components/main-nav.tsx`
-- `components/layout/layout-wrapper.tsx`
-
-**Changement** (ligne ~58-76) :
-
-```typescript
-// AVANT
-keycloakLogoutUrl.searchParams.append('kc_action', 'LOGOUT');
-
-// APRÈS
-keycloakLogoutUrl.searchParams.append('kc_action', 'LOGOUT');
-// Ajouter client_id pour forcer logout client spécifique
-if (process.env.NEXT_PUBLIC_KEYCLOAK_CLIENT_ID) {
- keycloakLogoutUrl.searchParams.append('client_id',
- process.env.NEXT_PUBLIC_KEYCLOAK_CLIENT_ID);
-}
-```
-
----
-
-### Action 8 : Améliorer gestion erreur refresh token
-
-**Fichier** : `app/api/auth/options.ts`
-
-**Changement** : Voir détails dans `IMPROVEMENTS_LOGIN_FLOW.md` section "Problème 7"
-
----
-
-## ✅ Checklist d'Implémentation
-
-### Phase 1 : Corrections Critiques (1-2 heures)
-- [ ] Action 1 : Supprimer `prompt=login` par défaut
-- [ ] Action 2 : Créer route `/api/auth/mark-logout`
-- [ ] Action 3 : Modifier signout-handler pour utiliser la route
-- [ ] Action 4 : Simplifier signin/page.tsx
-- [ ] Action 5 : Ajouter prompt=login conditionnel
-
-### Phase 2 : Améliorations (1 heure)
-- [ ] Action 6 : Configurer explicitement les cookies
-- [ ] Action 7 : Améliorer Keycloak logout URL
-- [ ] Action 8 : Améliorer gestion erreur refresh
-
-### Phase 3 : Tests (30 minutes)
-- [ ] Tester login première visite (SSO doit fonctionner)
-- [ ] Tester login après logout (credentials doivent être demandés)
-- [ ] Tester logout depuis dashboard
-- [ ] Tester logout depuis iframe
-- [ ] Tester expiration session
-
----
-
-## 🎯 Résultat Attendu
-
-### Avant
-- ❌ Toujours demander credentials (même première visite)
-- ❌ Logique complexe de détection session invalide
-- ❌ Race conditions possibles
-- ❌ Cookies Keycloak peuvent persister
-
-### Après
-- ✅ SSO naturel pour utilisateurs légitimes
-- ✅ Credentials demandés seulement après logout
-- ✅ Détection session invalide simple et robuste
-- ✅ Pas de race conditions
-- ✅ Meilleure gestion des cookies
-
----
-
-**Document créé le** : $(date)
-**Priorité** : Actions immédiates à faire en premier
-
diff --git a/AUDIT_API_N8N_CONNECTION.md b/AUDIT_API_N8N_CONNECTION.md
new file mode 100644
index 00000000..e97bc943
--- /dev/null
+++ b/AUDIT_API_N8N_CONNECTION.md
@@ -0,0 +1,724 @@
+# 🔍 Audit Développeur Senior - Connexion API Next.js ↔️ N8N (Missions)
+
+**Date**: $(date)
+**Auteur**: Audit Développeur Senior
+**Objectif**: Vérifier et documenter la connexion entre Next.js et N8N pour la gestion des missions
+
+---
+
+## 📋 Table des Matières
+
+1. [Architecture Globale](#architecture-globale)
+2. [Flux de Communication](#flux-de-communication)
+3. [Endpoints API](#endpoints-api)
+4. [Configuration Requise](#configuration-requise)
+5. [Sécurité](#sécurité)
+6. [Points Critiques à Vérifier](#points-critiques-à-vérifier)
+7. [Problèmes Potentiels et Solutions](#problèmes-potentiels-et-solutions)
+8. [Tests et Validation](#tests-et-validation)
+9. [Recommandations](#recommandations)
+
+---
+
+## 🏗️ Architecture Globale
+
+### Vue d'ensemble
+
+```
+┌─────────────┐ ┌─────────────┐ ┌─────────────┐
+│ Next.js │────────▶│ N8N │────────▶│ Intégrations│
+│ (API) │ │ (Workflow) │ │ (Gitea, etc)│
+└─────────────┘ └─────────────┘ └─────────────┘
+ │ │
+ │ │
+ └─────────────────────────┘
+ (Callback)
+```
+
+### Composants Principaux
+
+1. **Next.js API Routes**
+ - `POST /api/missions` - Création de mission
+ - `POST /api/missions/mission-created` - Callback de N8N
+ - `GET /api/missions` - Liste des missions
+
+2. **Service N8N** (`lib/services/n8n-service.ts`)
+ - Envoi de données vers N8N
+ - Gestion des webhooks
+ - Gestion des erreurs
+
+3. **N8N Workflows**
+ - Webhook de réception: `/webhook/mission-created`
+ - Création des intégrations externes
+ - Callback vers Next.js
+
+---
+
+## 🔄 Flux de Communication
+
+### 1. Création d'une Mission (Next.js → N8N → Next.js)
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ ÉTAPE 1: Création Mission dans Next.js │
+└─────────────────────────────────────────────────────────────────┘
+POST /api/missions
+ ↓
+1. Validation des données
+2. Création en base de données (Prisma)
+3. Upload des fichiers (logo, attachments) vers Minio
+4. Vérification des fichiers
+ ↓
+┌─────────────────────────────────────────────────────────────────┐
+│ ÉTAPE 2: Envoi vers N8N │
+└─────────────────────────────────────────────────────────────────┘
+POST https://brain.slm-lab.net/webhook/mission-created
+Headers:
+ - Content-Type: application/json
+ - x-api-key: {N8N_API_KEY}
+Body:
+ {
+ missionId: "uuid",
+ name: "...",
+ oddScope: [...],
+ services: [...],
+ config: {
+ N8N_API_KEY: "...",
+ MISSION_API_URL: "https://api.slm-lab.net/api"
+ },
+ ...
+ }
+ ↓
+┌─────────────────────────────────────────────────────────────────┐
+│ ÉTAPE 3: Traitement N8N │
+└─────────────────────────────────────────────────────────────────┘
+N8N Workflow:
+ 1. Réception webhook
+ 2. Création Gitea repository (si service "Gite")
+ 3. Création Leantime project (si service "Leantime")
+ 4. Création Outline collection (si service "Documentation")
+ 5. Création RocketChat channel (si service "RocketChat")
+ 6. Préparation des données de callback
+ ↓
+┌─────────────────────────────────────────────────────────────────┐
+│ ÉTAPE 4: Callback N8N → Next.js │
+└─────────────────────────────────────────────────────────────────┘
+POST {MISSION_API_URL}/api/missions/mission-created
+Headers:
+ - Content-Type: application/json
+ - x-api-key: {N8N_API_KEY} (depuis config.N8N_API_KEY)
+Body:
+ {
+ missionId: "uuid",
+ gitRepoUrl: "...",
+ leantimeProjectId: "...",
+ documentationCollectionId: "...",
+ rocketchatChannelId: "..."
+ }
+ ↓
+┌─────────────────────────────────────────────────────────────────┐
+│ ÉTAPE 5: Mise à jour Mission dans Next.js │
+└─────────────────────────────────────────────────────────────────┘
+Validation API key
+Recherche mission par missionId
+Mise à jour des champs d'intégration:
+ - giteaRepositoryUrl
+ - leantimeProjectId
+ - outlineCollectionId
+ - rocketChatChannelId
+```
+
+---
+
+## 🔌 Endpoints API
+
+### 1. POST /api/missions
+
+**Fichier**: `app/api/missions/route.ts`
+
+**Fonction**: Créer une nouvelle mission et déclencher le workflow N8N
+
+**Authentification**:
+- Session utilisateur requise (via `getServerSession`)
+- Vérification: `checkAuth(request)`
+
+**Body attendu**:
+```typescript
+{
+ name: string;
+ oddScope: string[];
+ niveau?: string;
+ intention?: string;
+ missionType?: string;
+ services?: string[];
+ guardians?: Record;
+ volunteers?: string[];
+ logo?: { data: string; name?: string; type?: string };
+ attachments?: Array<{ data: string; name?: string; type?: string }>;
+}
+```
+
+**Réponse**:
+```json
+{
+ "success": true,
+ "mission": { ... },
+ "message": "Mission created successfully with all integrations"
+}
+```
+
+**Points critiques**:
+- ✅ Mission créée en base AVANT l'envoi à N8N
+- ✅ Fichiers uploadés et vérifiés AVANT l'envoi à N8N
+- ✅ `missionId` inclus dans les données envoyées à N8N
+- ✅ `config.N8N_API_KEY` et `config.MISSION_API_URL` inclus
+
+---
+
+### 2. POST /api/missions/mission-created
+
+**Fichier**: `app/api/missions/mission-created/route.ts`
+
+**Fonction**: Recevoir les IDs d'intégration de N8N et mettre à jour la mission
+
+**Authentification**:
+- **API Key** via header `x-api-key`
+- **PAS** de session utilisateur requise (N8N n'a pas de session)
+
+**Headers requis**:
+```
+x-api-key: {N8N_API_KEY}
+Content-Type: application/json
+```
+
+**Body attendu**:
+```typescript
+{
+ missionId: string; // ✅ Préféré (plus fiable)
+ // OU (fallback pour compatibilité)
+ name: string;
+ creatorId: string;
+
+ // IDs d'intégration (optionnels)
+ gitRepoUrl?: string;
+ leantimeProjectId?: string | number;
+ documentationCollectionId?: string;
+ rocketchatChannelId?: string;
+}
+```
+
+**Réponse succès**:
+```json
+{
+ "success": true,
+ "message": "Mission updated successfully",
+ "mission": {
+ "id": "...",
+ "name": "...",
+ "giteaRepositoryUrl": "...",
+ "leantimeProjectId": "...",
+ "outlineCollectionId": "...",
+ "rocketChatChannelId": "..."
+ }
+}
+```
+
+**Codes d'erreur**:
+- `401` - API key invalide ou manquante
+- `400` - Champs requis manquants
+- `404` - Mission non trouvée
+- `500` - Erreur serveur
+
+**Points critiques**:
+- ✅ Validation stricte de l'API key
+- ✅ Recherche par `missionId` (préféré) ou `name + creatorId` (fallback)
+- ✅ Conversion `leantimeProjectId` de number vers string si nécessaire
+- ✅ Mise à jour uniquement des champs fournis
+
+---
+
+## ⚙️ Configuration Requise
+
+### Variables d'Environnement
+
+#### 1. N8N_API_KEY (OBLIGATOIRE)
+```env
+N8N_API_KEY=LwgeE1ntADD20OuWC88S3pR0EaO7FtO4
+```
+
+**Usage**:
+- Envoyé à N8N dans `config.N8N_API_KEY`
+- N8N l'utilise pour authentifier le callback
+- Vérifié côté serveur dans `/api/missions/mission-created`
+
+**Où configurer**:
+- `.env.local` (développement)
+- Variables d'environnement production (CapRover, Vercel, Docker, etc.)
+
+**Vérification**:
+```typescript
+// Erreur si non défini
+if (!process.env.N8N_API_KEY) {
+ logger.error('N8N_API_KEY is not set in environment variables');
+}
+```
+
+---
+
+#### 2. N8N_WEBHOOK_URL (Optionnel)
+```env
+N8N_WEBHOOK_URL=https://brain.slm-lab.net/webhook/mission-created
+```
+
+**Valeur par défaut**: `https://brain.slm-lab.net/webhook/mission-created`
+
+**Usage**: URL du webhook N8N pour la création de mission
+
+---
+
+#### 3. NEXT_PUBLIC_API_URL (Recommandé)
+```env
+NEXT_PUBLIC_API_URL=https://api.slm-lab.net/api
+```
+
+**Usage**:
+- Envoyé à N8N dans `config.MISSION_API_URL`
+- N8N l'utilise pour construire l'URL du callback
+- Format attendu: `{MISSION_API_URL}/api/missions/mission-created`
+
+**Valeur par défaut**: `https://api.slm-lab.net/api`
+
+---
+
+#### 4. N8N_ROLLBACK_WEBHOOK_URL (Optionnel)
+```env
+N8N_ROLLBACK_WEBHOOK_URL=https://brain.slm-lab.net/webhook/mission-rollback
+```
+
+**Usage**: URL du webhook N8N pour le rollback de mission
+
+---
+
+### Configuration N8N Workflow
+
+#### Webhook de Réception
+
+**Path**: `mission-created`
+**URL complète**: `https://brain.slm-lab.net/webhook/mission-created`
+**Méthode**: `POST`
+**Status**: Doit être **ACTIF** (toggle vert dans N8N)
+
+---
+
+#### Node "Save Mission To API"
+
+**URL**:
+```
+{{ $node['Process Mission Data'].json.config.MISSION_API_URL }}/api/missions/mission-created
+```
+
+**Méthode**: `POST`
+
+**Headers**:
+```
+Content-Type: application/json
+x-api-key: {{ $node['Process Mission Data'].json.config.N8N_API_KEY }}
+```
+
+**Body**:
+```json
+{
+ "missionId": "{{ $node['Process Mission Data'].json.missionId }}",
+ "gitRepoUrl": "{{ $node['Create Git Repo'].json.url }}",
+ "leantimeProjectId": "{{ $node['Create Leantime Project'].json.id }}",
+ "documentationCollectionId": "{{ $node['Create Outline Collection'].json.id }}",
+ "rocketchatChannelId": "{{ $node['Create RocketChat Channel'].json.id }}"
+}
+```
+
+**Points critiques**:
+- ✅ Utiliser `config.MISSION_API_URL` (pas d'URL en dur)
+- ✅ Utiliser `config.N8N_API_KEY` (pas de clé en dur)
+- ✅ Inclure `missionId` dans le body
+- ✅ Inclure tous les IDs d'intégration créés
+
+---
+
+## 🔒 Sécurité
+
+### 1. Authentification API Key
+
+**Mécanisme**:
+- N8N envoie `x-api-key` header
+- Next.js compare avec `process.env.N8N_API_KEY`
+- Si différent → `401 Unauthorized`
+
+**Code de validation** (`app/api/missions/mission-created/route.ts:42`):
+```typescript
+const apiKey = request.headers.get('x-api-key');
+const expectedApiKey = process.env.N8N_API_KEY;
+
+if (apiKey !== expectedApiKey) {
+ logger.error('Invalid API key', {
+ received: apiKey ? 'present' : 'missing',
+ expected: expectedApiKey ? 'configured' : 'missing'
+ });
+ return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
+}
+```
+
+**Points critiques**:
+- ✅ Comparaison stricte (pas de hash, clé en clair)
+- ✅ Logging des tentatives invalides
+- ✅ Pas de fallback si clé manquante
+
+---
+
+### 2. Transmission de la Clé API
+
+**Flux**:
+1. Next.js lit `process.env.N8N_API_KEY`
+2. Next.js envoie à N8N dans `config.N8N_API_KEY`
+3. N8N stocke temporairement dans le workflow
+4. N8N renvoie dans header `x-api-key` lors du callback
+
+**Risque**: Si `N8N_API_KEY` est `undefined` au moment de l'envoi:
+- N8N reçoit `undefined` ou chaîne vide
+- N8N envoie chaîne vide dans le header
+- Next.js rejette avec `401`
+
+**Solution**: Vérifier que `N8N_API_KEY` est défini avant l'envoi à N8N
+
+---
+
+### 3. Validation des Données
+
+**Côté Next.js**:
+- ✅ Validation des champs requis
+- ✅ Recherche de mission par `missionId` (plus sûr que `name + creatorId`)
+- ✅ Conversion de types (number → string pour `leantimeProjectId`)
+
+**Côté N8N**:
+- ⚠️ Pas de validation visible dans le code Next.js
+- ⚠️ N8N doit valider les données avant création des intégrations
+
+---
+
+## ⚠️ Points Critiques à Vérifier
+
+### 1. Configuration Environnement
+
+- [ ] `N8N_API_KEY` est défini dans l'environnement
+- [ ] `N8N_API_KEY` a la même valeur partout (dev, staging, prod)
+- [ ] `NEXT_PUBLIC_API_URL` pointe vers la bonne URL
+- [ ] Application redémarrée après modification des variables
+
+---
+
+### 2. Workflow N8N
+
+- [ ] Workflow est **ACTIF** (toggle vert)
+- [ ] Webhook path est correct: `mission-created`
+- [ ] Node "Save Mission To API" utilise `config.MISSION_API_URL`
+- [ ] Node "Save Mission To API" utilise `config.N8N_API_KEY`
+- [ ] Node "Save Mission To API" inclut `missionId` dans le body
+- [ ] Tous les IDs d'intégration sont inclus dans le callback
+
+---
+
+### 3. Flux de Données
+
+- [ ] `missionId` est envoyé à N8N lors de la création
+- [ ] `missionId` est renvoyé par N8N dans le callback
+- [ ] Les IDs d'intégration sont correctement mappés:
+ - `gitRepoUrl` → `giteaRepositoryUrl`
+ - `leantimeProjectId` → `leantimeProjectId` (string)
+ - `documentationCollectionId` → `outlineCollectionId`
+ - `rocketchatChannelId` → `rocketChatChannelId`
+
+---
+
+### 4. Gestion d'Erreurs
+
+- [ ] Erreurs N8N sont loggées
+- [ ] Rollback en cas d'échec (si configuré)
+- [ ] Messages d'erreur clairs pour debugging
+- [ ] Pas de données sensibles dans les logs
+
+---
+
+## 🐛 Problèmes Potentiels et Solutions
+
+### Problème 1: 401 Unauthorized
+
+**Symptômes**:
+```
+Invalid API key { received: 'present', expected: 'configured' }
+```
+
+**Causes possibles**:
+1. `N8N_API_KEY` non défini dans l'environnement
+2. `N8N_API_KEY` différent entre Next.js et N8N
+3. N8N envoie une clé vide ou `undefined`
+
+**Solutions**:
+1. Vérifier que `N8N_API_KEY` est défini:
+ ```bash
+ echo $N8N_API_KEY
+ ```
+2. Vérifier la valeur dans N8N:
+ - Ouvrir l'exécution du workflow
+ - Vérifier `config.N8N_API_KEY` dans "Process Mission Data"
+3. S'assurer que la même clé est utilisée partout
+
+---
+
+### Problème 2: 404 Mission Not Found
+
+**Symptômes**:
+```
+Mission not found { missionId: "...", name: "...", creatorId: "..." }
+```
+
+**Causes possibles**:
+1. `missionId` non envoyé par N8N
+2. `missionId` incorrect
+3. Mission supprimée entre temps
+
+**Solutions**:
+1. Vérifier que N8N envoie `missionId`:
+ ```json
+ {
+ "missionId": "{{ $node['Process Mission Data'].json.missionId }}"
+ }
+ ```
+2. Vérifier que Next.js envoie `missionId` à N8N:
+ ```typescript
+ config: {
+ missionId: mission.id // ✅ Inclus dans n8nData
+ }
+ ```
+3. Utiliser le fallback `name + creatorId` si `missionId` manquant
+
+---
+
+### Problème 3: 500 Server Configuration Error
+
+**Symptômes**:
+```
+N8N_API_KEY not configured in environment
+```
+
+**Cause**: `process.env.N8N_API_KEY` est `undefined`
+
+**Solution**:
+1. Ajouter `N8N_API_KEY` à `.env.local` ou variables d'environnement
+2. Redémarrer l'application
+3. Vérifier avec un endpoint de test
+
+---
+
+### Problème 4: 404 Webhook Not Registered
+
+**Symptômes**:
+```
+404 Error: The requested webhook "mission-created" is not registered.
+Hint: Click the 'Execute workflow' button on the canvas, then try again.
+```
+
+**Cause**: Workflow N8N n'est pas actif
+
+**Solution**:
+1. Ouvrir le workflow dans N8N
+2. Activer le toggle "Active" (devrait être vert)
+3. Vérifier que le webhook node est actif
+
+---
+
+### Problème 5: IDs d'Intégration Non Sauvegardés
+
+**Symptômes**:
+- Mission créée mais `giteaRepositoryUrl`, `leantimeProjectId`, etc. sont `null`
+
+**Causes possibles**:
+1. N8N ne rappelle pas `/api/missions/mission-created`
+2. N8N rappelle mais avec des IDs manquants
+3. Erreur lors de la mise à jour en base
+
+**Solutions**:
+1. Vérifier les logs N8N (Executions)
+2. Vérifier que le node "Save Mission To API" s'exécute
+3. Vérifier les logs Next.js pour "Mission Created Webhook Received"
+4. Vérifier que tous les IDs sont inclus dans le body du callback
+
+---
+
+## 🧪 Tests et Validation
+
+### Test 1: Vérifier Configuration
+
+**Endpoint de test** (à créer):
+```typescript
+// app/api/test-n8n-config/route.ts
+import { NextResponse } from 'next/server';
+
+export async function GET() {
+ return NextResponse.json({
+ hasN8NApiKey: !!process.env.N8N_API_KEY,
+ n8nApiKeyLength: process.env.N8N_API_KEY?.length || 0,
+ n8nWebhookUrl: process.env.N8N_WEBHOOK_URL || 'https://brain.slm-lab.net/webhook/mission-created',
+ missionApiUrl: process.env.NEXT_PUBLIC_API_URL || 'https://api.slm-lab.net/api'
+ });
+}
+```
+
+**Usage**: `GET /api/test-n8n-config`
+
+---
+
+### Test 2: Tester Webhook N8N
+
+```bash
+curl -X POST https://brain.slm-lab.net/webhook/mission-created \
+ -H "Content-Type: application/json" \
+ -d '{"test": "data"}'
+```
+
+**Résultats attendus**:
+- ✅ `200/400/500` avec erreur workflow: Webhook actif
+- ❌ `404` avec "webhook not registered": Webhook inactif
+
+---
+
+### Test 3: Tester Callback Endpoint
+
+```bash
+curl -X POST https://api.slm-lab.net/api/missions/mission-created \
+ -H "Content-Type: application/json" \
+ -H "x-api-key: YOUR_N8N_API_KEY" \
+ -d '{
+ "missionId": "test-mission-id",
+ "gitRepoUrl": "https://git.example.com/repo",
+ "leantimeProjectId": "123"
+ }'
+```
+
+**Résultats attendus**:
+- ✅ `200` avec `success: true`: API key valide
+- ❌ `401`: API key invalide
+- ❌ `404`: Mission non trouvée (normal si missionId de test)
+
+---
+
+### Test 4: Créer une Mission Complète
+
+1. Créer une mission via le frontend
+2. Vérifier les logs Next.js:
+ - ✅ "Mission created successfully"
+ - ✅ "Starting N8N workflow"
+ - ✅ "N8N workflow result { success: true }"
+3. Vérifier les logs N8N (Executions):
+ - ✅ Workflow exécuté avec succès
+ - ✅ Node "Save Mission To API" exécuté
+4. Vérifier la base de données:
+ - ✅ Mission a les IDs d'intégration sauvegardés
+
+---
+
+## 💡 Recommandations
+
+### 1. Amélioration de la Sécurité
+
+**Problème actuel**: Clé API en clair, comparaison simple
+
+**Recommandations**:
+- [ ] Utiliser un système de tokens avec expiration
+- [ ] Implémenter un système de signature HMAC
+- [ ] Ajouter un rate limiting sur `/api/missions/mission-created`
+- [ ] Logging des tentatives d'accès invalides avec IP
+
+---
+
+### 2. Amélioration de la Robustesse
+
+**Problème actuel**: Pas de retry automatique si N8N échoue
+
+**Recommandations**:
+- [ ] Implémenter un système de retry avec backoff exponentiel
+- [ ] Queue de messages pour les callbacks manqués
+- [ ] Webhook de santé pour vérifier que N8N est accessible
+- [ ] Timeout configurable pour les appels N8N
+
+---
+
+### 3. Amélioration du Debugging
+
+**Problème actuel**: Logs dispersés, pas de traçabilité complète
+
+**Recommandations**:
+- [ ] Ajouter un `correlationId` pour tracer une mission de bout en bout
+- [ ] Logs structurés avec contexte complet
+- [ ] Dashboard de monitoring des intégrations
+- [ ] Alertes en cas d'échec répété
+
+---
+
+### 4. Amélioration de la Documentation
+
+**Recommandations**:
+- [ ] Documenter le format exact attendu par N8N
+- [ ] Exemples de payloads complets
+- [ ] Diagrammes de séquence détaillés
+- [ ] Guide de troubleshooting avec cas réels
+
+---
+
+### 5. Tests Automatisés
+
+**Recommandations**:
+- [ ] Tests unitaires pour `N8nService`
+- [ ] Tests d'intégration pour les endpoints API
+- [ ] Tests E2E avec mock N8N
+- [ ] Tests de charge pour vérifier la scalabilité
+
+---
+
+## 📝 Checklist de Vérification Rapide
+
+### Configuration
+- [ ] `N8N_API_KEY` défini et identique partout
+- [ ] `NEXT_PUBLIC_API_URL` pointe vers la bonne URL
+- [ ] Application redémarrée après modifications
+
+### N8N Workflow
+- [ ] Workflow actif (toggle vert)
+- [ ] Webhook path: `mission-created`
+- [ ] Node "Save Mission To API" configuré correctement
+- [ ] `missionId` inclus dans le callback
+
+### Code Next.js
+- [ ] `missionId` envoyé à N8N lors de la création
+- [ ] Validation API key fonctionnelle
+- [ ] Mapping des champs correct
+- [ ] Gestion d'erreurs appropriée
+
+### Tests
+- [ ] Test de création de mission réussi
+- [ ] IDs d'intégration sauvegardés en base
+- [ ] Logs sans erreurs critiques
+
+---
+
+## 🔗 Références
+
+- **Service N8N**: `lib/services/n8n-service.ts`
+- **Endpoint création**: `app/api/missions/route.ts`
+- **Endpoint callback**: `app/api/missions/mission-created/route.ts`
+- **Documentation N8N**: Voir fichiers `N8N_*.md` dans le projet
+
+---
+
+**Document créé le**: $(date)
+**Dernière mise à jour**: $(date)
+**Version**: 1.0
+
diff --git a/AUTHENTICATION_FIXES.md b/AUTHENTICATION_FIXES.md
deleted file mode 100644
index c6f8d69b..00000000
--- a/AUTHENTICATION_FIXES.md
+++ /dev/null
@@ -1,224 +0,0 @@
-# Authentication Flow Fixes
-
-## Issues Fixed
-
-### 1. Logout Loop Issue ✅
-
-**Problem**:
-- User couldn't log out - infinite redirect loop
-- Sign-in page auto-triggered Keycloak login even when user was already authenticated
-- Keycloak session cookies weren't cleared, causing immediate re-authentication
-
-**Root Cause**:
-- `/signin` page had `useEffect(() => { signIn("keycloak") }, [])` that always triggered login
-- No check for existing authentication status
-- Keycloak logout endpoint was never called, leaving Keycloak cookies valid
-
-**Fix Applied**:
-1. **Sign-in page** (`app/signin/page.tsx`):
- - Added check for existing session before triggering login
- - If user is already authenticated, redirect to home
- - Only trigger Keycloak login if status is "unauthenticated"
-
-2. **Sign-out handler** (`components/auth/signout-handler.tsx`):
- - Now properly calls Keycloak logout endpoint
- - Uses ID token for proper logout
- - Clears both NextAuth and Keycloak cookies
-
-3. **Main navigation logout** (`components/main-nav.tsx`):
- - Fixed to use `idToken` instead of `accessToken` for Keycloak logout
- - Proper logout flow with Keycloak endpoint
-
----
-
-### 2. Iframe Applications Logging Out ✅
-
-**Problem**:
-- Iframe applications were logging out even when user was still authenticated in dashboard
-- Desynchronization between NextAuth session and Keycloak session
-
-**Root Cause**:
-- Sign-out only cleared NextAuth cookies
-- Keycloak session cookies remained valid but could expire independently
-- Iframe apps rely on Keycloak cookies for SSO
-- When Keycloak cookies expired/invalidated, iframes logged out but dashboard stayed logged in
-
-**Fix Applied**:
-1. **ID Token Storage** (`app/api/auth/options.ts`):
- - Now stores `idToken` from Keycloak in JWT
- - Exposes `idToken` in session object
- - Preserves ID token during token refresh
-
-2. **Proper Keycloak Logout**:
- - Sign-out now calls Keycloak logout endpoint with `id_token_hint`
- - This properly invalidates Keycloak session and clears Keycloak cookies
- - Ensures synchronization between dashboard and iframe apps
-
-3. **Type Definitions** (`types/next-auth.d.ts`):
- - Added `idToken` to Session and JWT interfaces
- - Type-safe access to ID token
-
----
-
-## Changes Made
-
-### Files Modified
-
-1. **`app/api/auth/options.ts`**
- - Added `idToken` to JWT interface
- - Store `account.id_token` in JWT during initial authentication
- - Expose `idToken` in session callback
- - Preserve `idToken` during token refresh
-
-2. **`app/signin/page.tsx`**
- - Added session status check
- - Prevent auto-login if already authenticated
- - Redirect authenticated users to home
-
-3. **`components/auth/signout-handler.tsx`**
- - Call Keycloak logout endpoint with ID token
- - Proper logout flow that clears both NextAuth and Keycloak sessions
-
-4. **`components/main-nav.tsx`**
- - Fixed logout button to use `idToken` instead of `accessToken`
- - Proper Keycloak logout flow
-
-5. **`types/next-auth.d.ts`**
- - Added `idToken?: string` to Session interface
- - Added `idToken?: string` to JWT interface (both modules)
-
----
-
-## How It Works Now
-
-### Sign-In Flow (Fixed)
-
-```
-1. User navigates to /signin
-2. Check session status:
- - If authenticated → Redirect to /
- - If unauthenticated → Trigger Keycloak login
-3. After Keycloak authentication:
- - Store tokens (access, refresh, ID token)
- - Initialize storage
- - Redirect to dashboard
-```
-
-### Sign-Out Flow (Fixed)
-
-```
-1. User clicks logout
-2. Sign out from NextAuth (clears NextAuth cookies)
-3. Call Keycloak logout endpoint:
- - URL: ${KEYCLOAK_ISSUER}/protocol/openid-connect/logout
- - Parameters:
- * post_logout_redirect_uri: /signin
- * id_token_hint:
-4. Keycloak clears its session and cookies
-5. Redirect to /signin (no auto-login loop)
-```
-
-### Iframe SSO (Fixed)
-
-```
-1. User authenticates in dashboard
-2. Keycloak sets session cookies
-3. Iframe apps read Keycloak cookies
-4. When user logs out:
- - Keycloak logout endpoint is called
- - Keycloak cookies are cleared
- - Iframe apps lose access (synchronized logout)
-```
-
----
-
-## Environment Variables Required
-
-Ensure these are set:
-
-```bash
-# Required for logout
-NEXT_PUBLIC_KEYCLOAK_ISSUER=https://keycloak.example.com/realms/neah
-
-# Already required for authentication
-KEYCLOAK_CLIENT_ID=neah-dashboard
-KEYCLOAK_CLIENT_SECRET=
-KEYCLOAK_ISSUER=https://keycloak.example.com/realms/neah
-NEXTAUTH_URL=https://dashboard.example.com
-NEXTAUTH_SECRET=
-```
-
-**Important**: `NEXT_PUBLIC_KEYCLOAK_ISSUER` must be set for client-side logout to work.
-
----
-
-## Testing Checklist
-
-### Logout Flow
-- [ ] Click logout button
-- [ ] Should redirect to Keycloak logout
-- [ ] Should redirect back to /signin
-- [ ] Should NOT auto-login (no loop)
-- [ ] Should be able to manually log in again
-
-### Sign-In Flow
-- [ ] Navigate to /signin when not authenticated
-- [ ] Should trigger Keycloak login
-- [ ] Navigate to /signin when already authenticated
-- [ ] Should redirect to / (no auto-login trigger)
-
-### Iframe SSO
-- [ ] Log in to dashboard
-- [ ] Open iframe application
-- [ ] Should be automatically authenticated
-- [ ] Log out from dashboard
-- [ ] Iframe application should also lose authentication
-- [ ] Refresh iframe - should require login
-
----
-
-## Additional Notes
-
-### ID Token vs Access Token
-
-- **Access Token**: Used for API calls to Keycloak-protected resources
-- **ID Token**: Used for user identification and logout
-- **Refresh Token**: Used to get new access tokens
-
-The ID token is required for proper Keycloak logout. It tells Keycloak which session to invalidate.
-
-### Cookie Synchronization
-
-The fix ensures that:
-1. NextAuth cookies are cleared (dashboard logout)
-2. Keycloak cookies are cleared (via logout endpoint)
-3. Both happen in sequence, maintaining synchronization
-
-### Token Refresh
-
-During token refresh, the ID token is preserved (Keycloak doesn't issue new ID tokens on refresh). This ensures logout continues to work even after token refreshes.
-
----
-
-## Troubleshooting
-
-### If logout still loops:
-
-1. Check browser console for errors
-2. Verify `NEXT_PUBLIC_KEYCLOAK_ISSUER` is set correctly
-3. Check that Keycloak logout endpoint is accessible
-4. Verify ID token is present in session: `console.log(session?.idToken)`
-
-### If iframes still log out independently:
-
-1. Check Keycloak cookie domain configuration
-2. Verify iframe apps are configured to use same Keycloak realm
-3. Check browser cookie settings (third-party cookies may be blocked)
-4. Verify Keycloak session timeout settings
-
----
-
-**Date**: 2024
-**Status**: ✅ Fixed
-**Version**: 1.0
-
diff --git a/AUTHENTICATION_FLOW_AUDIT.md b/AUTHENTICATION_FLOW_AUDIT.md
deleted file mode 100644
index c5a4be4e..00000000
--- a/AUTHENTICATION_FLOW_AUDIT.md
+++ /dev/null
@@ -1,988 +0,0 @@
-# Authentication Flow Audit - NextAuth with Keycloak & SSO for Iframe Applications
-
-## Executive Summary
-
-This document provides a comprehensive audit of the authentication architecture in the Neah dashboard application. The system uses **NextAuth.js v4** with **Keycloak** as the OAuth provider, implementing JWT-based sessions and supporting Single Sign-On (SSO) for multiple iframe-embedded applications via cookie-based authentication.
-
----
-
-## Architecture Overview
-
-### Components
-1. **NextAuth.js** - Authentication framework
-2. **Keycloak** - Identity Provider (IdP) via OAuth 2.0/OpenID Connect
-3. **JWT Strategy** - Session management (no database sessions)
-4. **Iframe Applications** - Multiple embedded applications using SSO via cookies
-5. **Keycloak Admin Client** - Server-side user management
-
----
-
-## 1. Authentication Entry Points
-
-### 1.1 Sign-In Page (`/app/signin/page.tsx`)
-
-**Location**: `app/signin/page.tsx`
-
-**Flow**:
-```typescript
-1. User navigates to /signin
-2. Component automatically triggers: signIn("keycloak", { callbackUrl: "/" })
-3. Redirects to Keycloak authorization endpoint
-4. After Keycloak authentication, initializes storage via /api/storage/init
-5. Redirects to home page
-```
-
-**Key Methods**:
-- `signIn("keycloak")` - NextAuth client-side method
-- Automatic redirect to Keycloak OAuth flow
-- Storage initialization after successful authentication
-
-**Dependencies**:
-- `next-auth/react` - Client-side NextAuth hooks
-- Storage API endpoint for user space initialization
-
----
-
-## 2. NextAuth Configuration
-
-### 2.1 Route Handler (`/app/api/auth/[...nextauth]/route.ts`)
-
-**Location**: `app/api/auth/[...nextauth]/route.ts`
-
-**Purpose**: NextAuth API route handler for all authentication endpoints
-
-**Endpoints Handled**:
-- `GET/POST /api/auth/signin` - Sign in
-- `GET/POST /api/auth/signout` - Sign out
-- `GET /api/auth/session` - Get current session
-- `GET /api/auth/csrf` - CSRF token
-- `GET /api/auth/providers` - Available providers
-- `GET /api/auth/callback/keycloak` - OAuth callback
-
-**Implementation**:
-```typescript
-import NextAuth from "next-auth";
-import { authOptions } from "../options";
-
-const handler = NextAuth(authOptions);
-export { handler as GET, handler as POST };
-```
-
----
-
-### 2.2 Auth Options Configuration (`/app/api/auth/options.ts`)
-
-**Location**: `app/api/auth/options.ts`
-
-**This is the core authentication configuration file.**
-
-#### 2.2.1 Keycloak Provider Setup
-
-```typescript
-KeycloakProvider({
- clientId: getRequiredEnvVar("KEYCLOAK_CLIENT_ID"),
- clientSecret: getRequiredEnvVar("KEYCLOAK_CLIENT_SECRET"),
- issuer: getRequiredEnvVar("KEYCLOAK_ISSUER"),
- authorization: {
- params: {
- scope: "openid profile email roles" // Requested OAuth scopes
- }
- },
- profile(profile) { /* Profile transformation */ }
-})
-```
-
-**Environment Variables Required**:
-- `KEYCLOAK_CLIENT_ID` - OAuth client identifier
-- `KEYCLOAK_CLIENT_SECRET` - OAuth client secret
-- `KEYCLOAK_ISSUER` - Keycloak realm issuer URL (e.g., `https://keycloak.example.com/realms/neah`)
-
-**OAuth Scopes Requested**:
-- `openid` - OpenID Connect core
-- `profile` - User profile information
-- `email` - User email address
-- `roles` - User roles from Keycloak realm
-
-#### 2.2.2 Profile Callback
-
-**Location**: Lines 109-137 in `options.ts`
-
-**Purpose**: Transforms Keycloak user profile into NextAuth user object
-
-**Process**:
-1. Receives Keycloak profile with `realm_access.roles`
-2. Extracts roles from `realm_access.roles` array
-3. Cleans roles by:
- - Removing `ROLE_` prefix (if present)
- - Converting to lowercase
-4. Maps Keycloak profile fields to NextAuth user:
- - `sub` → `id`
- - `name` or `preferred_username` → `name`
- - `email` → `email`
- - `given_name` → `first_name`
- - `family_name` → `last_name`
- - `preferred_username` → `username`
- - Cleaned roles → `role[]`
-
-**Code Flow**:
-```typescript
-profile(profile) {
- const roles = profile.realm_access?.roles || [];
- const cleanRoles = roles.map((role: string) =>
- role.replace(/^ROLE_/, '').toLowerCase()
- );
-
- return {
- id: profile.sub,
- name: profile.name ?? profile.preferred_username,
- email: profile.email,
- first_name: profile.given_name ?? '',
- last_name: profile.family_name ?? '',
- username: profile.preferred_username ?? profile.email?.split('@')[0] ?? '',
- role: cleanRoles,
- }
-}
-```
-
-#### 2.2.3 Session Configuration
-
-**Location**: Lines 140-143
-
-```typescript
-session: {
- strategy: "jwt", // JWT-based sessions (no database)
- maxAge: 30 * 24 * 60 * 60, // 30 days
-}
-```
-
-**Characteristics**:
-- **Strategy**: JWT (stateless, no database lookups)
-- **Max Age**: 30 days (2,592,000 seconds)
-- **Storage**: Encrypted JWT stored in HTTP-only cookies
-
-#### 2.2.4 JWT Callback
-
-**Location**: Lines 145-181
-
-**Purpose**: Handles JWT token creation and refresh
-
-**Flow**:
-
-**Initial Authentication (account & profile present)**:
-```typescript
-if (account && profile) {
- 1. Extract roles from Keycloak profile
- 2. Clean roles (remove ROLE_ prefix, lowercase)
- 3. Store in JWT token:
- - accessToken: account.access_token (Keycloak access token)
- - refreshToken: account.refresh_token (Keycloak refresh token)
- - accessTokenExpires: account.expires_at (expiration timestamp)
- - sub: Keycloak user ID
- - role: cleaned roles array
- - username, first_name, last_name: from profile
-}
-```
-
-**Subsequent Requests (token refresh check)**:
-```typescript
-else if (token.accessToken) {
- 1. Decode JWT to extract roles (if not already in token)
- 2. Check if token is expired:
- - If expired: Call refreshAccessToken()
- - If valid: Return existing token
-}
-```
-
-**Token Expiration Check**:
-```typescript
-if (Date.now() < (token.accessTokenExpires as number) * 1000) {
- return token; // Token still valid
-}
-return refreshAccessToken(token); // Token expired, refresh
-```
-
-**Note**: There's a **BUG** in line 176 - it multiplies `accessTokenExpires` by 1000, but `expires_at` from Keycloak is already in seconds since epoch. This should be checked.
-
-#### 2.2.5 Token Refresh Function
-
-**Location**: Lines 64-96
-
-**Purpose**: Refreshes expired Keycloak access tokens
-
-**Implementation**:
-```typescript
-async function refreshAccessToken(token: JWT) {
- 1. POST to Keycloak token endpoint:
- - URL: ${KEYCLOAK_ISSUER}/protocol/openid-connect/token
- - Method: POST
- - Body:
- * client_id: KEYCLOAK_CLIENT_ID
- * client_secret: KEYCLOAK_CLIENT_SECRET
- * grant_type: refresh_token
- * refresh_token: token.refreshToken
-
- 2. On Success:
- - Update accessToken
- - Update refreshToken (if new one provided)
- - Update accessTokenExpires: Date.now() + expires_in * 1000
-
- 3. On Error:
- - Set token.error = "RefreshAccessTokenError"
- - Return token with error flag
-}
-```
-
-**Error Handling**: Sets `token.error` flag which is checked in session callback
-
-#### 2.2.6 Session Callback
-
-**Location**: Lines 182-202
-
-**Purpose**: Transforms JWT token into session object for client-side use
-
-**Flow**:
-```typescript
-async session({ session, token }) {
- 1. Check for refresh errors:
- if (token.error) throw new Error(token.error)
-
- 2. Build session.user object:
- - id: token.sub (Keycloak user ID)
- - email: token.email
- - name: token.name
- - image: null
- - username: token.username
- - first_name: token.first_name
- - last_name: token.last_name
- - role: token.role (array)
- - nextcloudInitialized: false (default)
-
- 3. Add accessToken to session:
- session.accessToken = token.accessToken
-
- 4. Return session
-}
-```
-
-**Important**: The `accessToken` (Keycloak OAuth token) is exposed in the session object, making it available client-side via `useSession()` hook.
-
-#### 2.2.7 Custom Pages
-
-**Location**: Lines 204-207
-
-```typescript
-pages: {
- signIn: '/signin',
- error: '/signin',
-}
-```
-
-**Custom Routes**:
-- Sign-in page: `/signin` (instead of default `/api/auth/signin`)
-- Error page: `/signin` (redirects to sign-in on errors)
-
----
-
-## 3. Authentication Flow Step-by-Step
-
-### 3.1 Initial Sign-In Flow
-
-```
-┌─────────────┐
-│ Browser │
-└──────┬──────┘
- │
- │ 1. GET /signin
- ▼
-┌─────────────────────┐
-│ /app/signin/page.tsx │
-│ - Auto-triggers │
-│ signIn("keycloak") │
-└──────┬──────────────┘
- │
- │ 2. Redirect to NextAuth
- ▼
-┌──────────────────────────────┐
-│ /api/auth/signin/keycloak │
-│ - Generates OAuth state │
-│ - Redirects to Keycloak │
-└──────┬───────────────────────┘
- │
- │ 3. GET /realms/{realm}/protocol/openid-connect/auth
- │ ?client_id=...
- │ &redirect_uri=...
- │ &response_type=code
- │ &scope=openid profile email roles
- │ &state=...
- ▼
-┌─────────────────────┐
-│ Keycloak Server │
-│ - Login page │
-│ - User credentials │
-└──────┬──────────────┘
- │
- │ 4. User authenticates
- │
- │ 5. POST /realms/{realm}/protocol/openid-connect/token
- │ (Authorization code exchange)
- │
- │ 6. Keycloak returns:
- │ - access_token
- │ - refresh_token
- │ - id_token
- │ - expires_in
- ▼
-┌──────────────────────────────┐
-│ /api/auth/callback/keycloak │
-│ - Receives authorization code│
-│ - Exchanges for tokens │
-│ - Fetches user profile │
-└──────┬───────────────────────┘
- │
- │ 7. JWT Callback
- │ - Stores tokens in JWT
- │ - Extracts user info
- │ - Cleans roles
- │
- │ 8. Session Callback
- │ - Builds session object
- │
- │ 9. Sets NextAuth cookies:
- │ - next-auth.session-token (encrypted JWT)
- │ - next-auth.csrf-token
- ▼
-┌─────────────────────┐
-│ Browser (Client) │
-│ - Cookies set │
-│ - Redirect to / │
-└──────┬──────────────┘
- │
- │ 10. GET / (home page)
- │ - getServerSession() validates JWT
- │ - Session available
- ▼
-┌─────────────────────┐
-│ Dashboard Loaded │
-└─────────────────────┘
-```
-
-### 3.2 Subsequent Request Flow (Authenticated)
-
-```
-┌─────────────┐
-│ Browser │
-└──────┬──────┘
- │
- │ 1. GET /any-page
- │ Cookie: next-auth.session-token=...
- ▼
-┌──────────────────────────────┐
-│ Next.js Server │
-│ getServerSession(authOptions)│
-└──────┬───────────────────────┘
- │
- │ 2. Decrypt JWT from cookie
- │
- │ 3. Check token expiration
- │
- │ 4a. If valid:
- │ - Extract user info
- │ - Return session
- │
- │ 4b. If expired:
- │ - Call refreshAccessToken()
- │ - POST to Keycloak /token
- │ - Update JWT with new tokens
- │ - Return session
- ▼
-┌─────────────────────┐
-│ Page Component │
-│ - session available│
-└─────────────────────┘
-```
-
-### 3.3 Token Refresh Flow
-
-```
-┌─────────────────────┐
-│ JWT Callback │
-│ (Token expired) │
-└──────┬──────────────┘
- │
- │ 1. Call refreshAccessToken()
- │
- │ 2. POST ${KEYCLOAK_ISSUER}/protocol/openid-connect/token
- │ Body:
- │ - client_id
- │ - client_secret
- │ - grant_type: refresh_token
- │ - refresh_token:
- ▼
-┌─────────────────────┐
-│ Keycloak Server │
-│ - Validates refresh│
-│ token │
-│ - Issues new tokens│
-└──────┬──────────────┘
- │
- │ 3. Returns:
- │ - access_token (new)
- │ - refresh_token (new, optional)
- │ - expires_in
- ▼
-┌─────────────────────┐
-│ Update JWT Token │
-│ - New accessToken │
-│ - New refreshToken │
-│ - New expires time │
-└──────┬──────────────┘
- │
- │ 4. Return updated token
- │
- │ 5. Session callback builds session
- ▼
-┌─────────────────────┐
-│ Session Available │
-└─────────────────────┘
-```
-
----
-
-## 4. Iframe SSO Architecture
-
-### 4.1 Overview
-
-The dashboard embeds multiple applications in iframes. These applications rely on **cookie-based SSO** to authenticate users automatically using the Keycloak session established in the parent dashboard.
-
-### 4.2 Iframe Application Pages
-
-**Pattern**: All iframe pages follow the same structure:
-
-```typescript
-// Example: app/parole/page.tsx
-export default async function Page() {
- const session = await getServerSession(authOptions);
-
- if (!session) {
- redirect("/signin");
- }
-
- return (
-
- );
-}
-```
-
-**Iframe Applications Identified**:
-1. **Parole** (`/parole`) - `NEXT_PUBLIC_IFRAME_PAROLE_URL`
-2. **Agilite** (`/agilite`) - `NEXT_PUBLIC_IFRAME_AGILITY_URL`
-3. **Alma** (`/alma`) - `NEXT_PUBLIC_IFRAME_AI_ASSISTANT_URL`
-4. **Vision** (`/vision`) - `NEXT_PUBLIC_IFRAME_CONFERENCE_URL`
-5. **The Message** (`/the-message`) - `NEXT_PUBLIC_IFRAME_THEMESSAGE_URL`
-6. **WP Admin** (`/wp-admin`) - `NEXT_PUBLIC_IFRAME_MISSIONVIEW_URL`
-7. **Mediation** (`/mediation`) - `NEXT_PUBLIC_IFRAME_MEDIATIONS_URL`
-8. **Apprendre** (`/apprendre`) - `NEXT_PUBLIC_IFRAME_LEARN_URL`
-9. **Gite** (`/gite`) - `NEXT_PUBLIC_IFRAME_GITE_URL`
-10. **Artlab** (`/artlab`) - `NEXT_PUBLIC_IFRAME_ARTLAB_URL`
-11. **Calcul** (`/calcul`) - `NEXT_PUBLIC_IFRAME_CALCULATION_URL`
-12. **Chapitre** (`/chapitre`) - `NEXT_PUBLIC_IFRAME_CHAPTER_URL`
-13. **Dossiers** (`/dossiers`) - `NEXT_PUBLIC_IFRAME_DRIVE_URL`
-14. **CRM** (`/crm`) - `NEXT_PUBLIC_IFRAME_MEDIATIONS_URL`
-15. **Livres** (`/livres`) - `NEXT_PUBLIC_IFRAME_LIVRE_URL`
-16. **Showcase** (`/showcase`) - `NEXT_PUBLIC_IFRAME_SHOWCASE_URL`
-17. **Radio** (`/radio`) - `NEXT_PUBLIC_IFRAME_RADIO_URL`
-18. **Press** (`/press`) - `NEXT_PUBLIC_IFRAME_SHOWCASE_URL`
-19. **Observatory** - `NEXT_PUBLIC_IFRAME_OBSERVATORY_URL`
-20. **Time Tracker** - `NEXT_PUBLIC_IFRAME_TIMETRACKER_URL`
-21. **Missions Board** - `NEXT_PUBLIC_IFRAME_MISSIONSBOARD_URL`
-22. **Carnet** - `NEXT_PUBLIC_IFRAME_CARNET_URL`
-
-### 4.3 SSO Cookie Mechanism
-
-**How It Works**:
-
-1. **Parent Dashboard Authentication**:
- - User authenticates via Keycloak in the dashboard
- - Keycloak sets authentication cookies (domain: Keycloak domain)
- - NextAuth sets session cookies (domain: dashboard domain)
-
-2. **Iframe Cookie Sharing**:
- - When iframe loads, browser sends cookies for the iframe's domain
- - If iframe application is on **same domain** or **subdomain** of Keycloak:
- - Keycloak cookies are automatically sent
- - Application can read Keycloak session cookies
- - SSO works automatically
-
-3. **Cross-Domain Considerations**:
- - If iframe apps are on different domains, they need:
- - Same Keycloak realm configuration
- - Proper CORS settings
- - Cookie domain configuration in Keycloak
- - `SameSite=None; Secure` cookie attributes for cross-site
-
-### 4.4 ResponsiveIframe Component
-
-**Location**: `app/components/responsive-iframe.tsx`
-
-**Features**:
-- Auto-resizing based on viewport
-- Hash synchronization (URL fragments)
-- Full-screen support
-
-**Important**: This component does **NOT** handle authentication - it's purely presentational. SSO relies on browser cookie behavior.
-
----
-
-## 5. Sign-Out Flow
-
-### 5.1 Sign-Out Page
-
-**Location**: `app/signout/page.tsx`
-
-**Implementation**:
-```typescript
-export default function SignOut() {
- return (
-
-
-
Déconnexion en cours...
-
- ↓
-[Backend]
- GET /api/missions/image/[...path]
- ↓
- Lecture depuis Minio
- ↓
- Stream vers client
-```
-
----
-
-## 🎨 Styles et UI
-
-### Couleurs des Badges Niveau
-- **A (Apprentissage)**: `bg-green-100 text-green-800`
-- **B (Basique)**: `bg-blue-100 text-blue-800`
-- **C (Complexe)**: `bg-purple-100 text-purple-800`
-- **S (Spécial)**: `bg-amber-100 text-amber-800`
-
-### Layout Sidebar CAP
-- **Fond**: `bg-pink-50`
-- **Bordure**: `border-pink-100`
-- **Largeur**: `234px` fixe
-
-### Grille de Missions
-- **Mobile**: 1 colonne
-- **Tablet**: 2 colonnes (`md:grid-cols-2`)
-- **Desktop**: 3 colonnes (`lg:grid-cols-3`)
-
----
-
-## 🐛 Points d'Attention
-
-1. **Credentials Minio hardcodés** dans `lib/mission-uploads.ts` - À déplacer vers variables d'environnement
-2. **Rollback N8N non implémenté** lors de la suppression
-3. **Skills tab non fonctionnel** - Placeholders uniquement
-4. **Presigned URLs non implémentées** - Upload direct uniquement
-5. **Gestion d'erreurs N8N** - Partielle (continue même si certaines intégrations échouent)
-
----
-
-## 📝 Notes Techniques
-
-### Types TypeScript
-
-**Mission Interface** (utilisée dans les pages):
-```typescript
-interface Mission {
- id: string;
- name: string;
- logo?: string;
- logoUrl?: string;
- oddScope: string[];
- niveau: string;
- missionType: string;
- projection: string;
- participation?: string;
- services?: string[];
- profils?: string[];
- intention?: string;
- donneurDOrdre?: string;
- createdAt: string;
- creator: User;
- missionUsers: MissionUser[];
- attachments?: Attachment[];
-}
-```
-
-### Validation
-
-**Côté Frontend**: Validation dans `MissionsAdminPanel.validateMission()`
-**Côté Backend**: Validation minimale (name et oddScope requis)
-
-### Gestion d'Erreurs
-
-- **Frontend**: Toast notifications via `useToast()`
-- **Backend**: Retour JSON avec `error` et `details`
-- **N8N**: Retour avec `success` et `failedServices` pour erreurs partielles
-
----
-
-## 🔄 Évolutions Possibles
-
-1. **Pagination** côté client pour les listes
-2. **Filtres avancés** (par niveau, type, ODD, etc.)
-3. **Recherche full-text** dans l'intention
-4. **Export** des missions (PDF, CSV)
-5. **Notifications** lors de l'assignation à une mission
-6. **Statistiques** des missions
-7. **Timeline** des activités d'une mission
-8. **Commentaires** sur les missions
-9. **États** des missions (brouillon, publiée, terminée, etc.)
-10. **Permissions granulaires** par rôle de gardien
-
----
-
-**Document généré le**: $(date)
-**Version**: 1.0
-**Auteur**: Analyse automatique du codebase
-
diff --git a/MISSION_CREATION_WORKFLOW_DETAILED.md b/MISSION_CREATION_WORKFLOW_DETAILED.md
deleted file mode 100644
index c7a91d55..00000000
--- a/MISSION_CREATION_WORKFLOW_DETAILED.md
+++ /dev/null
@@ -1,982 +0,0 @@
-# Workflow Détaillé : Création de Mission - Prisma, Minio et N8N
-
-## 📋 Vue d'Ensemble
-
-Ce document trace **chaque étape** du workflow de création de mission, depuis le formulaire frontend jusqu'aux intégrations externes via N8N, en passant par Prisma (base de données) et Minio (stockage de fichiers).
-
----
-
-## 🔄 Flux Complet - Vue d'Ensemble
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│ 1. FRONTEND - MissionsAdminPanel │
-│ - Validation des champs │
-│ - Préparation des données (base64 pour fichiers) │
-│ - POST /api/missions │
-└─────────────────────────────────────────────────────────────┘
- ↓
-┌─────────────────────────────────────────────────────────────┐
-│ 2. BACKEND - POST /api/missions │
-│ ├─ Authentification (NextAuth) │
-│ ├─ Validation des champs requis │
-│ ├─ STEP 1: Prisma.mission.create() │
-│ ├─ STEP 2: Prisma.missionUser.createMany() │
-│ ├─ STEP 3: Upload Logo → Minio │
-│ ├─ STEP 4: Upload Attachments → Minio │
-│ ├─ STEP 5: Vérification fichiers Minio │
-│ └─ STEP 6: N8N Workflow Trigger │
-└─────────────────────────────────────────────────────────────┘
- ↓
-┌─────────────────────────────────────────────────────────────┐
-│ 3. N8N WORKFLOW │
-│ - Création Leantime Project │
-│ - Création Outline Collection │
-│ - Création RocketChat Channel │
-│ - Création Gitea Repository │
-│ - Création Penpot Project │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## 📝 ÉTAPE 1 : Frontend - Préparation des Données
-
-### Fichier : `components/missions/missions-admin-panel.tsx`
-
-### 1.1 Validation (`validateMission()`)
-
-**Lignes 369-397**
-
-```typescript
-const validateMission = () => {
- const requiredFields = {
- name: !!missionData.name,
- oddScope: Array.isArray(missionData.oddScope) && missionData.oddScope.length > 0,
- niveau: !!missionData.niveau,
- intention: !!missionData.intention,
- missionType: !!missionData.missionType,
- donneurDOrdre: !!missionData.donneurDOrdre,
- projection: !!missionData.projection,
- participation: !!missionData.participation,
- gardiens: gardienDuTemps !== null &&
- gardienDeLaParole !== null &&
- gardienDeLaMemoire !== null
- };
-
- // Vérifie que tous les champs requis sont remplis
- // Retourne false si un champ manque
-}
-```
-
-**Champs requis** :
-- ✅ `name` : Nom de la mission
-- ✅ `oddScope` : Array avec au moins 1 ODD
-- ✅ `niveau` : A/B/C/S
-- ✅ `intention` : Description
-- ✅ `missionType` : remote/onsite/hybrid
-- ✅ `donneurDOrdre` : individual/group/organization
-- ✅ `projection` : short/medium/long
-- ✅ `participation` : volontaire/cooptation
-- ✅ `gardiens` : Les 3 gardiens doivent être assignés
-
-### 1.2 Préparation des Données (`handleSubmitMission()`)
-
-**Lignes 400-460**
-
-```typescript
-const handleSubmitMission = async () => {
- // 1. Validation
- if (!validateMission()) return;
-
- // 2. Préparation des gardiens
- const guardians = {
- "gardien-temps": gardienDuTemps,
- "gardien-parole": gardienDeLaParole,
- "gardien-memoire": gardienDeLaMemoire
- };
-
- // 3. Construction de l'objet de soumission
- const missionSubmitData = {
- ...missionData, // name, oddScope, niveau, intention, etc.
- services: selectedServices, // ["Gite", "ArtLab", "Calcul"]
- profils: selectedProfils, // ["DataIntelligence", "Expression", ...]
- guardians, // { "gardien-temps": userId, ... }
- volunteers: volontaires, // [userId1, userId2, ...]
- logo: missionData.logo // { data: "data:image/png;base64,...", name, type }
- };
-
- // 4. Envoi à l'API
- const response = await fetch('/api/missions', {
- method: 'POST',
- headers: { 'Content-Type': 'application/json' },
- body: JSON.stringify(missionSubmitData)
- });
-}
-```
-
-**Format du logo** (si présent) :
-```typescript
-logo: {
- data: "data:image/png;base64,iVBORw0KGgoAAAANS...", // Base64 avec préfixe
- name: "logo.png",
- type: "image/png"
-}
-```
-
-**Format des attachments** (si présents) :
-```typescript
-attachments: [
- {
- data: "data:application/pdf;base64,JVBERi0xLjQKJe...",
- name: "document.pdf",
- type: "application/pdf"
- }
-]
-```
-
----
-
-## 🗄️ ÉTAPE 2 : Backend - POST /api/missions
-
-### Fichier : `app/api/missions/route.ts`
-
-### 2.1 Authentification et Validation
-
-**Lignes 205-224**
-
-```typescript
-export async function POST(request: Request) {
- // 1. Vérification de l'authentification
- const { authorized, userId } = await checkAuth(request);
- if (!authorized || !userId) {
- return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
- }
-
- // 2. Parsing du body
- const body = await request.json();
-
- // 3. Validation minimale (name et oddScope requis)
- if (!body.name || !body.oddScope) {
- return NextResponse.json({
- error: 'Missing required fields',
- missingFields: ['name', 'oddScope'].filter(field => !body[field])
- }, { status: 400 });
- }
-}
-```
-
-### 2.2 STEP 1 : Création de la Mission en Base de Données
-
-**Lignes 226-248**
-
-```typescript
-// Préparation des données pour Prisma
-const missionData = {
- name: body.name,
- oddScope: body.oddScope, // Array de strings
- niveau: body.niveau,
- intention: body.intention,
- missionType: body.missionType,
- donneurDOrdre: body.donneurDOrdre,
- projection: body.projection,
- services: body.services, // Array de strings
- profils: body.profils, // Array de strings
- participation: body.participation,
- creatorId: userId, // ID de l'utilisateur connecté
- logo: null, // Sera mis à jour après upload
-};
-
-// Création en base de données
-const mission = await prisma.mission.create({
- data: missionData
-});
-
-// Résultat : mission.id est maintenant disponible
-// Exemple : mission.id = "abc-123-def-456"
-```
-
-**Schéma Prisma** :
-```prisma
-model Mission {
- id String @id @default(uuid())
- name String
- logo String? // null pour l'instant
- oddScope String[]
- niveau String
- intention String
- missionType String
- donneurDOrdre String
- projection String
- services String[]
- participation String?
- profils String[]
- creatorId String
- createdAt DateTime @default(now())
- updatedAt DateTime @updatedAt
- // Relations
- creator User @relation(...)
- missionUsers MissionUser[]
- attachments Attachment[]
-}
-```
-
-**Points importants** :
-- ✅ La mission est créée **AVANT** l'upload des fichiers
-- ✅ Le `mission.id` est généré automatiquement (UUID)
-- ✅ Le champ `logo` est `null` pour l'instant
-- ✅ Tous les champs sont sauvegardés sauf les fichiers
-
-### 2.3 STEP 2 : Création des MissionUsers (Gardiens + Volontaires)
-
-**Lignes 250-283**
-
-```typescript
-// Préparation du tableau de MissionUsers
-const missionUsers = [];
-
-// 2.1 Ajout des gardiens
-if (body.guardians) {
- for (const [role, guardianId] of Object.entries(body.guardians)) {
- if (guardianId) {
- missionUsers.push({
- missionId: mission.id, // ID de la mission créée
- userId: guardianId, // ID de l'utilisateur gardien
- role: role // "gardien-temps", "gardien-parole", "gardien-memoire"
- });
- }
- }
-}
-
-// 2.2 Ajout des volontaires
-if (body.volunteers && body.volunteers.length > 0) {
- for (const volunteerId of body.volunteers) {
- missionUsers.push({
- missionId: mission.id,
- userId: volunteerId,
- role: 'volontaire'
- });
- }
-}
-
-// 2.3 Création en batch dans Prisma
-if (missionUsers.length > 0) {
- await prisma.missionUser.createMany({
- data: missionUsers
- });
-}
-```
-
-**Schéma Prisma MissionUser** :
-```prisma
-model MissionUser {
- id String @id @default(uuid())
- role String // 'gardien-temps', 'gardien-parole', 'gardien-memoire', 'volontaire'
- missionId String
- userId String
- createdAt DateTime @default(now())
- updatedAt DateTime @updatedAt
-
- mission Mission @relation(...)
- user User @relation(...)
-
- @@unique([missionId, userId, role]) // Un utilisateur ne peut avoir qu'un rôle par mission
-}
-```
-
-**Exemple de données créées** :
-```typescript
-missionUsers = [
- { missionId: "abc-123", userId: "user-1", role: "gardien-temps" },
- { missionId: "abc-123", userId: "user-2", role: "gardien-parole" },
- { missionId: "abc-123", userId: "user-3", role: "gardien-memoire" },
- { missionId: "abc-123", userId: "user-4", role: "volontaire" },
- { missionId: "abc-123", userId: "user-5", role: "volontaire" }
-]
-```
-
-**Points importants** :
-- ✅ Utilisation de `createMany()` pour performance (1 requête au lieu de N)
-- ✅ Contrainte unique : un utilisateur ne peut avoir qu'un rôle par mission
-- ✅ Les gardiens sont obligatoires, les volontaires optionnels
-
-### 2.4 STEP 3 : Upload du Logo vers Minio
-
-**Lignes 285-310**
-
-```typescript
-let logoPath = null;
-if (body.logo?.data) {
- try {
- // 3.1 Conversion base64 → Buffer → File
- const base64Data = body.logo.data.split(',')[1]; // Retire "data:image/png;base64,"
- const buffer = Buffer.from(base64Data, 'base64');
- const file = new File(
- [buffer],
- body.logo.name || 'logo.png',
- { type: body.logo.type || 'image/png' }
- );
-
- // 3.2 Upload vers Minio
- const { filePath } = await uploadMissionLogo(userId, mission.id, file);
- logoPath = filePath; // Ex: "missions/abc-123/logo.png"
- uploadedFiles.push({ type: 'logo', path: filePath });
-
- // 3.3 Mise à jour de la mission avec le chemin du logo
- await prisma.mission.update({
- where: { id: mission.id },
- data: { logo: filePath }
- });
- } catch (uploadError) {
- throw new Error('Failed to upload logo');
- }
-}
-```
-
-**Fonction `uploadMissionLogo()` - `lib/mission-uploads.ts`** :
-
-**Lignes 96-145**
-
-```typescript
-export async function uploadMissionLogo(
- userId: string,
- missionId: string,
- file: File
-): Promise<{ filePath: string }> {
-
- // 1. Génération du chemin
- const fileExtension = file.name.substring(file.name.lastIndexOf('.'));
- const filePath = getMissionLogoPath(userId, missionId, fileExtension);
- // Résultat : "missions/{missionId}/logo.png"
-
- // 2. Conversion pour Minio (retire le préfixe "missions/")
- const minioPath = filePath.replace(/^missions\//, '');
- // Résultat : "{missionId}/logo.png"
-
- // 3. Conversion File → Buffer
- const arrayBuffer = await file.arrayBuffer();
- const buffer = Buffer.from(arrayBuffer);
-
- // 4. Upload vers Minio via S3 SDK
- await s3Client.send(new PutObjectCommand({
- Bucket: 'missions', // Bucket Minio
- Key: minioPath, // "{missionId}/logo.png"
- Body: buffer, // Contenu du fichier
- ContentType: file.type, // "image/png"
- ACL: 'public-read' // Accès public en lecture
- }));
-
- return { filePath }; // Retourne le chemin complet avec préfixe
-}
-```
-
-**Configuration Minio** :
-```typescript
-// lib/mission-uploads.ts
-const s3Client = new S3Client({
- region: 'us-east-1',
- endpoint: 'https://dome-api.slm-lab.net', // Endpoint Minio
- credentials: {
- accessKeyId: '4aBT4CMb7JIMMyUtp4Pl',
- secretAccessKey: 'HGn39XhCIlqOjmDVzRK9MED2Fci2rYvDDgbLFElg'
- },
- forcePathStyle: true // Requis pour MinIO
-});
-```
-
-**Structure dans Minio** :
-```
-Bucket: missions
- └── {missionId}/
- └── logo.png
-```
-
-**Points importants** :
-- ✅ Le logo est uploadé **APRÈS** la création de la mission (pour avoir le missionId)
-- ✅ Le chemin est mis à jour dans Prisma après l'upload
-- ✅ Le fichier est stocké avec ACL `public-read` pour accès public
-- ✅ Le chemin stocké inclut le préfixe `missions/` pour cohérence
-
-### 2.5 STEP 4 : Upload des Attachments vers Minio
-
-**Lignes 312-343**
-
-```typescript
-if (body.attachments && body.attachments.length > 0) {
- try {
- // 4.1 Traitement parallèle de tous les attachments
- const attachmentPromises = body.attachments.map(async (attachment: any) => {
- // Conversion base64 → Buffer → File
- const base64Data = attachment.data.split(',')[1];
- const buffer = Buffer.from(base64Data, 'base64');
- const file = new File(
- [buffer],
- attachment.name || 'attachment',
- { type: attachment.type || 'application/octet-stream' }
- );
-
- // 4.2 Upload vers Minio
- const { filePath, filename, fileType, fileSize } =
- await uploadMissionAttachment(userId, mission.id, file);
- uploadedFiles.push({ type: 'attachment', path: filePath });
-
- // 4.3 Création de l'enregistrement Attachment en base
- return prisma.attachment.create({
- data: {
- missionId: mission.id,
- filename, // "document.pdf"
- filePath, // "missions/abc-123/attachments/document.pdf"
- fileType, // "application/pdf"
- fileSize, // 123456 (bytes)
- uploaderId: userId
- }
- });
- });
-
- // 4.4 Attente de tous les uploads (parallèle)
- await Promise.all(attachmentPromises);
- } catch (attachmentError) {
- throw new Error('Failed to upload attachments');
- }
-}
-```
-
-**Fonction `uploadMissionAttachment()` - `lib/mission-uploads.ts`** :
-
-**Lignes 148-210**
-
-```typescript
-export async function uploadMissionAttachment(
- userId: string,
- missionId: string,
- file: File
-): Promise<{
- filename: string;
- filePath: string;
- fileType: string;
- fileSize: number;
-}> {
-
- // 1. Génération du chemin
- const filePath = getMissionAttachmentPath(userId, missionId, file.name);
- // Résultat : "missions/{missionId}/attachments/{filename}"
-
- // 2. Conversion pour Minio
- const minioPath = filePath.replace(/^missions\//, '');
- // Résultat : "{missionId}/attachments/{filename}"
-
- // 3. Conversion File → Buffer
- const arrayBuffer = await file.arrayBuffer();
- const buffer = Buffer.from(arrayBuffer);
-
- // 4. Upload vers Minio
- await s3Client.send(new PutObjectCommand({
- Bucket: 'missions',
- Key: minioPath,
- Body: buffer,
- ContentType: file.type,
- ACL: 'public-read'
- }));
-
- return {
- filename: file.name,
- filePath, // Chemin complet avec préfixe
- fileType: file.type,
- fileSize: file.size
- };
-}
-```
-
-**Schéma Prisma Attachment** :
-```prisma
-model Attachment {
- id String @id @default(uuid())
- filename String // "document.pdf"
- filePath String // "missions/{missionId}/attachments/{filename}"
- fileType String // "application/pdf"
- fileSize Int // 123456
- missionId String
- uploaderId String
- createdAt DateTime @default(now())
- updatedAt DateTime @updatedAt
-
- mission Mission @relation(...)
- uploader User @relation(...)
-}
-```
-
-**Structure dans Minio** :
-```
-Bucket: missions
- └── {missionId}/
- ├── logo.png
- └── attachments/
- ├── document1.pdf
- ├── document2.docx
- └── image.jpg
-```
-
-**Points importants** :
-- ✅ Uploads en **parallèle** avec `Promise.all()` pour performance
-- ✅ Chaque attachment crée un enregistrement Prisma séparé
-- ✅ Le `uploaderId` est l'utilisateur qui a créé la mission
-- ✅ Les fichiers sont stockés avec ACL `public-read`
-
-### 2.6 STEP 5 : Vérification des Fichiers dans Minio
-
-**Lignes 345-365**
-
-```typescript
-// 5.1 Vérification du logo
-if (logoPath) {
- const logoExists = await verifyFileExists(logoPath);
- if (!logoExists) {
- throw new Error('Logo file not found in Minio');
- }
-}
-
-// 5.2 Vérification des attachments
-if (body.attachments?.length > 0) {
- const attachmentVerifications = uploadedFiles
- .filter(f => f.type === 'attachment')
- .map(f => verifyFileExists(f.path));
-
- const attachmentResults = await Promise.all(attachmentVerifications);
- if (attachmentResults.some(exists => !exists)) {
- throw new Error('One or more attachment files not found in Minio');
- }
-}
-```
-
-**Fonction `verifyFileExists()` - Lignes 191-202**
-
-```typescript
-async function verifyFileExists(filePath: string): Promise {
- try {
- await s3Client.send(new HeadObjectCommand({
- Bucket: 'missions',
- Key: filePath.replace('missions/', '') // Retire le préfixe
- }));
- return true; // Fichier existe
- } catch (error) {
- return false; // Fichier n'existe pas
- }
-}
-```
-
-**Points importants** :
-- ✅ Vérification **AVANT** de déclencher N8N
-- ✅ Utilise `HeadObjectCommand` (légère, ne télécharge pas le fichier)
-- ✅ Si un fichier manque, le workflow s'arrête avec erreur
-
-### 2.7 STEP 6 : Déclenchement du Workflow N8N
-
-**Lignes 367-393**
-
-```typescript
-// 6.1 Préparation des données pour N8N
-const n8nData = {
- ...body, // Toutes les données de la mission
- creatorId: userId, // ID du créateur
- logoPath: logoPath, // Chemin du logo (ou null)
- config: {
- N8N_API_KEY: process.env.N8N_API_KEY,
- MISSION_API_URL: process.env.NEXT_PUBLIC_API_URL
- }
-};
-
-// 6.2 Déclenchement du workflow
-const n8nService = new N8nService();
-const workflowResult = await n8nService.triggerMissionCreation(n8nData);
-
-// 6.3 Vérification du résultat
-if (!workflowResult.success) {
- throw new Error(workflowResult.error || 'N8N workflow failed');
-}
-
-// 6.4 Retour succès
-return NextResponse.json({
- success: true,
- mission,
- message: 'Mission created successfully with all integrations'
-});
-```
-
----
-
-## 🔗 ÉTAPE 3 : Service N8N
-
-### Fichier : `lib/services/n8n-service.ts`
-
-### 3.1 Configuration
-
-**Lignes 3-17**
-
-```typescript
-export class N8nService {
- private webhookUrl: string;
- private rollbackWebhookUrl: string;
- private apiKey: string;
-
- constructor() {
- this.webhookUrl = process.env.N8N_WEBHOOK_URL ||
- 'https://brain.slm-lab.net/webhook/mission-created';
- this.rollbackWebhookUrl = process.env.N8N_ROLLBACK_WEBHOOK_URL ||
- 'https://brain.slm-lab.net/webhook/mission-rollback';
- this.apiKey = process.env.N8N_API_KEY || '';
- }
-}
-```
-
-### 3.2 Nettoyage et Validation des Données
-
-**Lignes 19-49**
-
-```typescript
-async triggerMissionCreation(data: any): Promise {
- // Nettoyage des données
- const cleanData = {
- name: data.name,
- oddScope: Array.isArray(data.oddScope) ? data.oddScope : [data.oddScope],
- niveau: data.niveau || 'default',
- intention: data.intention?.trim() || '',
- missionType: data.missionType || 'default',
- donneurDOrdre: data.donneurDOrdre || 'default',
- projection: data.projection || 'default',
- services: Array.isArray(data.services) ? data.services : [],
- participation: data.participation || 'default',
- profils: Array.isArray(data.profils) ? data.profils : [],
- guardians: data.guardians || {},
- volunteers: Array.isArray(data.volunteers) ? data.volunteers : [],
- creatorId: data.creatorId,
- config: {
- ...data.config,
- N8N_API_KEY: this.apiKey,
- MISSION_API_URL: process.env.NEXT_PUBLIC_API_URL || 'https://api.slm-lab.net/api'
- }
- };
-}
-```
-
-**Points importants** :
-- ✅ Normalisation des arrays (assure qu'ils sont bien des arrays)
-- ✅ Valeurs par défaut pour éviter les undefined
-- ✅ Trim de l'intention pour retirer les espaces
-- ✅ Conservation de la config avec les clés API
-
-### 3.3 Envoi au Webhook N8N
-
-**Lignes 73-96**
-
-```typescript
-const response = await fetch(this.webhookUrl, {
- method: 'POST',
- headers: {
- 'Content-Type': 'application/json',
- 'x-api-key': this.apiKey // Authentification
- },
- body: JSON.stringify(cleanData)
-});
-
-if (!response.ok) {
- const errorText = await response.text();
- throw new Error(`HTTP error! status: ${response.status}, body: ${errorText}`);
-}
-```
-
-### 3.4 Traitement de la Réponse
-
-**Lignes 98-143**
-
-```typescript
-const responseText = await response.text();
-
-try {
- const result = JSON.parse(responseText);
-
- // Détection d'erreurs partielles
- if (result.error || result.message?.includes('failed')) {
- const errorMessage = result.message || result.error;
- const failedServices = {
- gitRepo: errorMessage.includes('Git repository creation failed'),
- leantimeProject: errorMessage.includes('Leantime project creation failed'),
- docCollection: errorMessage.includes('Documentation collection creation failed'),
- rocketChatChannel: errorMessage.includes('RocketChat channel creation failed')
- };
-
- // Retourne succès avec erreurs partielles
- return {
- success: true,
- results: { ...result, failedServices }
- };
- }
-
- return { success: true, results: result };
-
-} catch (parseError) {
- // Si la réponse n'est pas JSON, considère comme succès
- return {
- success: true,
- results: {
- logoUrl: null,
- leantimeProjectId: null,
- outlineCollectionId: null,
- rocketChatChannelId: null,
- giteaRepositoryUrl: null
- }
- };
-}
-```
-
-**Format de réponse attendu de N8N** :
-```json
-{
- "leantimeProjectId": "project-123",
- "outlineCollectionId": "collection-456",
- "rocketChatChannelId": "channel-789",
- "giteaRepositoryUrl": "https://git.slm-lab.net/mission-abc",
- "penpotProjectId": "penpot-xyz"
-}
-```
-
-**Intégrations créées par N8N** :
-1. **Leantime** : Projet de gestion de projet
-2. **Outline** : Collection de documentation
-3. **RocketChat** : Canal de communication
-4. **Gitea** : Repository Git
-5. **Penpot** : Projet de design
-
-**Points importants** :
-- ✅ Gestion des erreurs partielles (certains services peuvent échouer)
-- ✅ Si la réponse n'est pas JSON, considère comme succès (workflow déclenché)
-- ✅ Les IDs retournés ne sont **PAS** sauvegardés en base (TODO)
-
----
-
-## 🧹 Gestion des Erreurs et Cleanup
-
-### Fichier : `app/api/missions/route.ts` - Lignes 398-418
-
-```typescript
-catch (error) {
- console.error('Error in mission creation:', error);
-
- // Cleanup: Suppression de tous les fichiers uploadés
- for (const file of uploadedFiles) {
- try {
- await s3Client.send(new DeleteObjectCommand({
- Bucket: 'missions',
- Key: file.path.replace('missions/', '')
- }));
- console.log('Cleaned up file:', file.path);
- } catch (cleanupError) {
- console.error('Error cleaning up file:', file.path, cleanupError);
- }
- }
-
- return NextResponse.json({
- error: 'Failed to create mission',
- details: error instanceof Error ? error.message : String(error)
- }, { status: 500 });
-}
-```
-
-**Scénarios de cleanup** :
-1. ✅ Erreur lors de l'upload du logo → Suppression du logo
-2. ✅ Erreur lors de l'upload d'un attachment → Suppression de tous les fichiers
-3. ✅ Erreur lors de la vérification Minio → Suppression de tous les fichiers
-4. ✅ Erreur N8N → Suppression de tous les fichiers
-
-**Points importants** :
-- ✅ La mission reste en base même en cas d'erreur (orphan)
-- ✅ Les MissionUsers restent en base même en cas d'erreur
-- ✅ Seuls les fichiers Minio sont nettoyés
-- ⚠️ **TODO** : Rollback complet (suppression mission + users si erreur)
-
----
-
-## 📊 Résumé des Opérations Prisma
-
-### Requêtes Prisma dans l'ordre d'exécution :
-
-1. **`prisma.mission.create()`**
- - Crée la mission avec tous les champs
- - Génère un UUID pour `id`
- - `logo` = `null` initialement
-
-2. **`prisma.missionUser.createMany()`**
- - Crée tous les gardiens et volontaires en une requête
- - Utilise `createMany()` pour performance
-
-3. **`prisma.mission.update()`** (si logo)
- - Met à jour le champ `logo` avec le chemin Minio
-
-4. **`prisma.attachment.create()`** (pour chaque attachment)
- - Créé en parallèle avec `Promise.all()`
- - Un enregistrement par fichier
-
-**Total** : 1 + 1 + (0 ou 1) + N requêtes Prisma
-- Minimum : 2 requêtes (mission + users)
-- Avec logo : 3 requêtes
-- Avec N attachments : 3 + N requêtes
-
----
-
-## 📦 Résumé des Opérations Minio
-
-### Uploads Minio dans l'ordre d'exécution :
-
-1. **Logo** (si présent)
- - Bucket : `missions`
- - Key : `{missionId}/logo.png`
- - Path stocké : `missions/{missionId}/logo.png`
-
-2. **Attachments** (si présents, en parallèle)
- - Bucket : `missions`
- - Key : `{missionId}/attachments/{filename}`
- - Path stocké : `missions/{missionId}/attachments/{filename}`
-
-3. **Vérifications** (après uploads)
- - `HeadObjectCommand` pour chaque fichier
- - Vérifie l'existence avant N8N
-
-**Total** : 1 + N uploads + (1 + N) vérifications
-
----
-
-## 🔄 Résumé du Workflow N8N
-
-### Données envoyées à N8N :
-
-```typescript
-{
- name: "Mission Example",
- oddScope: ["odd-3"],
- niveau: "a",
- intention: "Description...",
- missionType: "remote",
- donneurDOrdre: "individual",
- projection: "short",
- services: ["Gite", "ArtLab"],
- participation: "volontaire",
- profils: ["DataIntelligence", "Expression"],
- guardians: {
- "gardien-temps": "user-1",
- "gardien-parole": "user-2",
- "gardien-memoire": "user-3"
- },
- volunteers: ["user-4", "user-5"],
- creatorId: "user-creator",
- logoPath: "missions/abc-123/logo.png",
- config: {
- N8N_API_KEY: "...",
- MISSION_API_URL: "https://api.slm-lab.net/api"
- }
-}
-```
-
-### Actions N8N (workflow interne) :
-
-1. Création projet Leantime
-2. Création collection Outline
-3. Création canal RocketChat
-4. Création repository Gitea
-5. Création projet Penpot
-
-**Note** : Les IDs retournés ne sont **PAS** sauvegardés en base actuellement.
-
----
-
-## ⚠️ Points d'Attention et TODOs
-
-### 1. Sauvegarde des IDs N8N
-**Problème** : Les IDs retournés par N8N (leantimeProjectId, etc.) ne sont pas sauvegardés en base.
-
-**Solution proposée** :
-```typescript
-// Après le workflow N8N
-if (workflowResult.success && workflowResult.results) {
- await prisma.mission.update({
- where: { id: mission.id },
- data: {
- leantimeProjectId: workflowResult.results.leantimeProjectId,
- outlineCollectionId: workflowResult.results.outlineCollectionId,
- rocketChatChannelId: workflowResult.results.rocketChatChannelId,
- giteaRepositoryUrl: workflowResult.results.giteaRepositoryUrl,
- penpotProjectId: workflowResult.results.penpotProjectId
- }
- });
-}
-```
-
-### 2. Rollback Complet
-**Problème** : En cas d'erreur, la mission reste en base (orphan).
-
-**Solution proposée** :
-```typescript
-catch (error) {
- // Suppression de la mission et des relations
- await prisma.mission.delete({ where: { id: mission.id } });
- // Les MissionUsers et Attachments seront supprimés en cascade
- // Nettoyage Minio...
-}
-```
-
-### 3. Credentials Minio Hardcodés
-**Problème** : Les credentials Minio sont hardcodés dans `lib/mission-uploads.ts`.
-
-**Solution** : Déplacer vers variables d'environnement.
-
-### 4. Gestion des Erreurs N8N Partielles
-**Problème** : Si certains services N8N échouent, on continue quand même.
-
-**Solution** : Décider si on continue ou on rollback selon la criticité.
-
----
-
-## 📈 Performance et Optimisations
-
-### Optimisations actuelles :
-- ✅ `createMany()` pour MissionUsers (1 requête au lieu de N)
-- ✅ `Promise.all()` pour les attachments (parallèle)
-- ✅ `HeadObjectCommand` pour vérification (léger)
-
-### Optimisations possibles :
-- 🔄 Transaction Prisma pour atomicité
-- 🔄 Batch upload Minio (si supporté)
-- 🔄 Retry logic pour N8N
-- 🔄 Cache des vérifications Minio
-
----
-
-## 🔍 Debugging et Logs
-
-### Points de logging importants :
-
-1. **Début du workflow** : `=== Mission Creation Started ===`
-2. **Création Prisma** : `Mission created successfully`
-3. **Upload Minio** : `Logo upload successful` / `Attachment upload successful`
-4. **Vérification** : `verifyFileExists()` logs
-5. **N8N** : `=== Starting N8N Workflow ===` / `N8N Workflow Result`
-6. **Erreurs** : Tous les catch blocks loggent les erreurs
-
-### Commandes de debug :
-
-```bash
-# Voir les logs du serveur
-npm run dev # Logs dans la console
-
-# Vérifier Minio
-# Accéder à https://dome-api.slm-lab.net
-# Bucket: missions
-
-# Vérifier Prisma
-npx prisma studio # Interface graphique
-```
-
----
-
-**Document généré le** : $(date)
-**Version** : 1.0
-**Auteur** : Analyse complète du codebase
-
diff --git a/MISSION_DELETION_IDS_EMPTY_ANALYSIS.md b/MISSION_DELETION_IDS_EMPTY_ANALYSIS.md
deleted file mode 100644
index 6bf6b769..00000000
--- a/MISSION_DELETION_IDS_EMPTY_ANALYSIS.md
+++ /dev/null
@@ -1,377 +0,0 @@
-# Analyse : IDs Vides lors de la Suppression de Mission
-
-## 🔍 Problème
-
-Lors de la suppression d'une mission, N8N reçoit des IDs vides :
-
-```json
-{
- "repoName": "",
- "leantimeProjectId": 0,
- "documentationCollectionId": "",
- "rocketchatChannelId": "",
- "giteaRepositoryUrl": null,
- "outlineCollectionId": null,
- "rocketChatChannelId": null
-}
-```
-
-**Cela signifie que les IDs ne sont PAS sauvegardés en base lors de la création.**
-
----
-
-## 🔄 Flow de Création (Théorique)
-
-```
-1. POST /api/missions
- ↓
-2. Crée mission en Prisma (sans IDs)
- ↓
-3. Upload logo dans Minio
- ↓
-4. POST N8N webhook (mission-created)
- ↓
-5. N8N crée intégrations :
- - Gitea → retourne html_url
- - Leantime → retourne projectId
- - Outline → retourne collectionId
- - RocketChat → retourne channelId
- ↓
-6. N8N → POST /mission-created (avec les IDs)
- ↓
-7. Backend sauvegarde les IDs en base ✅
-```
-
----
-
-## ❌ Problèmes Possibles
-
-### Problème 1: N8N n'appelle pas `/mission-created`
-
-**Symptôme** : Les IDs ne sont jamais sauvegardés
-
-**Vérification** :
-- Vérifier les logs N8N : le node "Save Mission To API" est-il exécuté ?
-- Vérifier les logs backend : y a-t-il des appels à `/mission-created` ?
-- Vérifier les erreurs N8N : le workflow s'arrête-t-il avant "Save Mission To API" ?
-
-**Solution** :
-- Vérifier que le node "Save Mission To API" est bien connecté dans le workflow
-- Vérifier que l'URL est correcte : `{{ MISSION_API_URL }}/mission-created`
-- Vérifier que l'API key est correcte dans les headers
-
----
-
-### Problème 2: N8N appelle `/mission-created` mais sans `missionId`
-
-**Symptôme** : L'endpoint ne trouve pas la mission
-
-**Vérification** :
-- Vérifier les logs backend :
- ```
- === Mission Created Webhook Received ===
- Looking up mission by ID: ...
- Mission not found: ...
- ```
-- Vérifier le body reçu par `/mission-created` : contient-il `missionId` ?
-
-**Solution** :
-- Modifier le workflow N8N pour inclure `missionId` dans le body :
- ```json
- {
- "missionId": "={{ $node['Process Mission Data'].json.missionId }}",
- ...
- }
- ```
-
----
-
-### Problème 3: N8N appelle `/mission-created` mais les IDs sont vides
-
-**Symptôme** : L'endpoint trouve la mission mais les IDs sont `null` ou vides
-
-**Vérification** :
-- Vérifier les logs backend :
- ```
- Received mission-created data: {
- missionId: "...",
- gitRepoUrl: null, // ❌ Vide
- leantimeProjectId: null, // ❌ Vide
- ...
- }
- ```
-- Vérifier les logs N8N : les nodes de création retournent-ils bien les IDs ?
-
-**Solution** :
-- Vérifier que les nodes N8N (Create Git Repository, Create Leantime Project, etc.) retournent bien les IDs
-- Vérifier que le node "Combine Results" combine correctement les IDs
-- Vérifier que le node "Save Mission To API" utilise les bons chemins pour les IDs
-
----
-
-### Problème 4: Mapping incorrect des champs
-
-**Symptôme** : Les IDs sont envoyés mais avec des noms incorrects
-
-**Vérification** :
-- Vérifier le body envoyé par N8N :
- ```json
- {
- "gitRepoUrl": "...", // ✅ Correct
- "leantimeProjectId": "...", // ✅ Correct
- "documentationCollectionId": "...", // ✅ Correct
- "rocketchatChannelId": "..." // ✅ Correct
- }
- ```
-- Vérifier le mapping dans `/mission-created` :
- - `gitRepoUrl` → `giteaRepositoryUrl` ✅
- - `documentationCollectionId` → `outlineCollectionId` ✅
- - `rocketchatChannelId` → `rocketChatChannelId` ✅
-
-**Solution** :
-- Vérifier que les noms de champs correspondent exactement
-
----
-
-### Problème 5: API Key incorrecte
-
-**Symptôme** : L'endpoint retourne 401 Unauthorized
-
-**Vérification** :
-- Vérifier les logs backend :
- ```
- Invalid API key: { received: '...', expected: '...' }
- ```
-- Vérifier que `N8N_API_KEY` est bien configuré dans l'environnement
-- Vérifier que N8N envoie bien `x-api-key` dans les headers
-
-**Solution** :
-- Vérifier la variable d'environnement `N8N_API_KEY`
-- Vérifier que N8N utilise la bonne API key dans le header
-
----
-
-## 🔍 Points de Vérification
-
-### 1. Vérifier les Logs Backend
-
-**Lors de la création** :
-```
-=== Starting N8N Workflow ===
-Sending to N8N: { missionId: "...", ... }
-N8N Workflow Result: { success: true, ... }
-```
-
-**Lors de l'appel `/mission-created`** :
-```
-=== Mission Created Webhook Received ===
-Received mission-created data: { ... }
-Looking up mission by ID: ...
-Found mission: { id: "...", ... }
-Mission updated successfully: { ... }
-```
-
-**Si ces logs n'apparaissent pas** → N8N n'appelle pas `/mission-created`
-
----
-
-### 2. Vérifier les Logs N8N
-
-**Dans le workflow N8N** :
-- Le node "Save Mission To API" est-il exécuté ?
-- Y a-t-il des erreurs dans ce node ?
-- Le body envoyé contient-il les IDs ?
-
-**Vérifier le body du node "Save Mission To API"** :
-```json
-{
- "missionId": "={{ $node['Process Mission Data'].json.missionId }}",
- "gitRepoUrl": "={{ $node['Combine Results'].json.gitRepo?.html_url }}",
- "leantimeProjectId": "={{ $node['Combine Results'].json.leantimeProject?.result?.[0] }}",
- "documentationCollectionId": "={{ $node['Combine Results'].json.docCollection?.data?.id }}",
- "rocketchatChannelId": "={{ $node['Combine Results'].json.rocketChatChannel?.channel?._id }}"
-}
-```
-
----
-
-### 3. Vérifier la Base de Données
-
-**Requête SQL** :
-```sql
-SELECT
- id,
- name,
- giteaRepositoryUrl,
- leantimeProjectId,
- outlineCollectionId,
- rocketChatChannelId,
- createdAt,
- updatedAt
-FROM Mission
-WHERE name = 'Creation'
-ORDER BY createdAt DESC
-LIMIT 1;
-```
-
-**Résultat attendu** :
-```
-id: cd0225cf-8dfd-4bf0-a20a-6aa9c04ebb42
-name: Creation
-giteaRepositoryUrl: https://gite.slm-lab.net/alma/creation ✅
-leantimeProjectId: 123 ✅
-outlineCollectionId: collection-456 ✅
-rocketChatChannelId: channel-789 ✅
-```
-
-**Si tous les IDs sont `null`** → Ils ne sont pas sauvegardés
-
----
-
-## 📋 Checklist de Diagnostic
-
-### Étape 1: Vérifier que N8N reçoit missionId
-
-- [ ] Les logs backend montrent `missionId` dans `n8nData`
-- [ ] N8N reçoit bien `missionId` dans le webhook
-
-### Étape 2: Vérifier que N8N crée les intégrations
-
-- [ ] Les logs N8N montrent que les nodes de création sont exécutés
-- [ ] Les nodes retournent bien les IDs (html_url, projectId, etc.)
-
-### Étape 3: Vérifier que N8N combine les résultats
-
-- [ ] Le node "Combine Results" contient les IDs
-- [ ] Les IDs sont accessibles via les chemins corrects
-
-### Étape 4: Vérifier que N8N appelle `/mission-created`
-
-- [ ] Les logs backend montrent des appels à `/mission-created`
-- [ ] Le node "Save Mission To API" est exécuté dans N8N
-- [ ] Pas d'erreur 401 (API key) ou 404 (mission not found)
-
-### Étape 5: Vérifier que les IDs sont sauvegardés
-
-- [ ] Les logs backend montrent "Mission updated successfully"
-- [ ] La base de données contient les IDs après création
-- [ ] Les IDs sont correctement mappés
-
----
-
-## 🎯 Actions Recommandées (Sans Toucher au Code)
-
-### 1. Vérifier les Logs Backend
-
-```bash
-# Chercher les appels à /mission-created
-grep "Mission Created Webhook Received" logs.txt
-
-# Chercher les erreurs
-grep "Mission not found" logs.txt
-grep "Invalid API key" logs.txt
-```
-
-### 2. Vérifier le Workflow N8N
-
-1. Ouvrir le workflow `NeahMissionCreate`
-2. Vérifier que le node "Save Mission To API" :
- - Est bien connecté après "Combine Results"
- - Contient `missionId` dans le body
- - Utilise les bons chemins pour les IDs
- - A l'URL correcte : `{{ MISSION_API_URL }}/mission-created`
- - A l'API key correcte dans les headers
-
-### 3. Tester Manuellement
-
-**Appel manuel à `/mission-created`** :
-```bash
-curl -X POST https://hub.slm-lab.net/api/missions/mission-created \
- -H "Content-Type: application/json" \
- -H "x-api-key: YOUR_API_KEY" \
- -d '{
- "missionId": "cd0225cf-8dfd-4bf0-a20a-6aa9c04ebb42",
- "name": "Creation",
- "creatorId": "user-id",
- "gitRepoUrl": "https://gite.slm-lab.net/alma/creation",
- "leantimeProjectId": "123",
- "documentationCollectionId": "collection-456",
- "rocketchatChannelId": "channel-789"
- }'
-```
-
-**Vérifier la réponse** :
-- 200 OK → L'endpoint fonctionne
-- 401 Unauthorized → Problème d'API key
-- 404 Not Found → Problème de recherche de mission
-- 400 Bad Request → Problème de validation
-
-### 4. Vérifier la Base de Données
-
-```sql
--- Vérifier une mission spécifique
-SELECT * FROM Mission WHERE id = 'cd0225cf-8dfd-4bf0-a20a-6aa9c04ebb42';
-
--- Vérifier les missions récentes sans IDs
-SELECT id, name, createdAt
-FROM Mission
-WHERE giteaRepositoryUrl IS NULL
- AND leantimeProjectId IS NULL
- AND outlineCollectionId IS NULL
- AND rocketChatChannelId IS NULL
-ORDER BY createdAt DESC
-LIMIT 10;
-```
-
----
-
-## 🔧 Solutions Probables
-
-### Solution 1: Ajouter missionId dans N8N
-
-**Dans le node "Save Mission To API"** :
-```json
-{
- "missionId": "={{ $node['Process Mission Data'].json.missionId }}",
- ...
-}
-```
-
-### Solution 2: Vérifier les Chemins des IDs dans N8N
-
-**Vérifier que les chemins sont corrects** :
-- `gitRepo.html_url` (pas `gitRepo.body.html_url`)
-- `leantimeProject.result[0]` (array avec index 0)
-- `docCollection.data.id` (pas `docCollection.id`)
-- `rocketChatChannel.channel._id` (pas `rocketChatChannel._id`)
-
-### Solution 3: Vérifier l'API Key
-
-**Vérifier que** :
-- `N8N_API_KEY` est configuré dans `.env`
-- N8N utilise la même clé dans le header `x-api-key`
-
----
-
-## 📝 Résumé
-
-**Le problème est que les IDs ne sont pas sauvegardés en base.**
-
-**Causes possibles** :
-1. ❌ N8N n'appelle pas `/mission-created`
-2. ❌ N8N appelle mais sans `missionId` → mission non trouvée
-3. ❌ N8N appelle mais les IDs sont vides dans le body
-4. ❌ API key incorrecte → 401 Unauthorized
-5. ❌ Mapping incorrect des champs
-
-**Action immédiate** :
-1. Vérifier les logs backend pour voir si `/mission-created` est appelé
-2. Vérifier le workflow N8N pour voir si `missionId` est inclus
-3. Vérifier la base de données pour voir si les IDs sont sauvegardés
-
----
-
-**Date**: $(date)
-**Status**: Analyse sans modification de code
-**Action Requise**: Vérification des logs et du workflow N8N
-
diff --git a/MISSION_DELETION_WORKFLOW.md b/MISSION_DELETION_WORKFLOW.md
deleted file mode 100644
index 14c88f35..00000000
--- a/MISSION_DELETION_WORKFLOW.md
+++ /dev/null
@@ -1,625 +0,0 @@
-# Workflow Détaillé : Suppression de Mission - Centrale (/missions)
-
-## 📋 Vue d'Ensemble
-
-Ce document trace **chaque étape** du workflow de suppression d'une mission depuis la page Centrale (`/missions/[missionId]`), incluant les vérifications de permissions, la suppression des fichiers Minio, et la suppression en base de données.
-
----
-
-## 🔄 Flux Complet - Vue d'Ensemble
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│ 1. FRONTEND - MissionDetailPage │
-│ - Clic sur bouton "Supprimer" │
-│ - Confirmation utilisateur (confirm dialog) │
-│ - DELETE /api/missions/[missionId] │
-└─────────────────────────────────────────────────────────────┘
- ↓
-┌─────────────────────────────────────────────────────────────┐
-│ 2. BACKEND - DELETE /api/missions/[missionId] │
-│ ├─ Authentification (NextAuth) │
-│ ├─ Vérification mission existe │
-│ ├─ Vérification permissions (créateur ou admin) │
-│ ├─ STEP 1: Suppression logo Minio (si existe) │
-│ ├─ STEP 2: Rollback N8N (TODO - non implémenté) │
-│ └─ STEP 3: Suppression mission Prisma (CASCADE) │
-└─────────────────────────────────────────────────────────────┘
- ↓
-┌─────────────────────────────────────────────────────────────┐
-│ 3. PRISMA CASCADE │
-│ - Suppression automatique MissionUsers │
-│ - Suppression automatique Attachments │
-│ ⚠️ Fichiers Minio des attachments NON supprimés │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## 📝 ÉTAPE 1 : Frontend - Clic sur Supprimer
-
-### Fichier : `app/missions/[missionId]/page.tsx`
-
-### 1.1 Bouton Supprimer
-
-**Lignes 397-411**
-
-```typescript
-
-```
-
-**Caractéristiques** :
-- ✅ Bouton rouge avec icône Trash2
-- ✅ Désactivé pendant la suppression (`deleting` state)
-- ✅ Affiche un spinner pendant le traitement
-
-### 1.2 Handler de Suppression
-
-**Lignes 143-176**
-
-```typescript
-const handleDeleteMission = async () => {
- // 1. Confirmation utilisateur
- if (!confirm("Êtes-vous sûr de vouloir supprimer cette mission ? Cette action est irréversible.")) {
- return; // Annulation si l'utilisateur refuse
- }
-
- try {
- setDeleting(true); // Active le spinner
-
- // 2. Appel API DELETE
- const response = await fetch(`/api/missions/${missionId}`, {
- method: 'DELETE',
- });
-
- // 3. Vérification de la réponse
- if (!response.ok) {
- throw new Error('Failed to delete mission');
- }
-
- // 4. Notification de succès
- toast({
- title: "Mission supprimée",
- description: "La mission a été supprimée avec succès",
- });
-
- // 5. Redirection vers la liste des missions
- router.push('/missions');
-
- } catch (error) {
- console.error('Error deleting mission:', error);
- toast({
- title: "Erreur",
- description: "Impossible de supprimer la mission",
- variant: "destructive",
- });
- } finally {
- setDeleting(false); // Désactive le spinner
- }
-};
-```
-
-**Points importants** :
-- ✅ **Double confirmation** : Dialog natif du navigateur
-- ✅ **Gestion d'état** : `deleting` pour le spinner
-- ✅ **Redirection automatique** vers `/missions` en cas de succès
-- ✅ **Gestion d'erreurs** avec toast notification
-
----
-
-## 🗄️ ÉTAPE 2 : Backend - DELETE /api/missions/[missionId]
-
-### Fichier : `app/api/missions/[missionId]/route.ts`
-
-### 2.1 Authentification et Récupération de la Mission
-
-**Lignes 292-316**
-
-```typescript
-export async function DELETE(
- request: Request,
- props: { params: Promise<{ missionId: string }> }
-) {
- const params = await props.params;
-
- try {
- // 1. Vérification de l'authentification
- const session = await getServerSession(authOptions);
- if (!session?.user) {
- return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
- }
-
- // 2. Récupération de la mission avec relations
- const mission = await prisma.mission.findUnique({
- where: { id: params.missionId },
- include: {
- missionUsers: {
- include: {
- user: true // Inclut les infos des utilisateurs
- }
- }
- }
- });
-
- // 3. Vérification que la mission existe
- if (!mission) {
- return NextResponse.json({ error: 'Mission not found' }, { status: 404 });
- }
-```
-
-**Points importants** :
-- ✅ Vérification de session NextAuth
-- ✅ Récupération de la mission avec `missionUsers` (pour logging/info)
-- ✅ Retour 404 si mission n'existe pas
-
-### 2.2 Vérification des Permissions
-
-**Lignes 318-324**
-
-```typescript
-// Vérification : utilisateur doit être créateur OU admin
-const isCreator = mission.creatorId === session.user.id;
-const userRoles = Array.isArray(session.user.role) ? session.user.role : [];
-const isAdmin = userRoles.includes('admin') || userRoles.includes('ADMIN');
-
-if (!isCreator && !isAdmin) {
- return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
-}
-```
-
-**Règles de permissions** :
-- ✅ **Créateur** : Peut supprimer sa propre mission
-- ✅ **Admin** : Peut supprimer n'importe quelle mission
-- ❌ **Autres utilisateurs** : Même gardiens/volontaires ne peuvent pas supprimer
-
-**Points importants** :
-- ✅ Vérification stricte : seul le créateur ou un admin peut supprimer
-- ✅ Les gardiens (même gardien-memoire) ne peuvent pas supprimer
-- ✅ Retour 403 Forbidden si pas autorisé
-
-### 2.3 STEP 1 : Suppression du Logo dans Minio
-
-**Lignes 326-334**
-
-```typescript
-// Suppression du logo si présent
-if (mission.logo) {
- try {
- await deleteMissionLogo(params.missionId, mission.logo);
- } catch (error) {
- console.error('Error deleting mission logo:', error);
- // Continue deletion even if logo deletion fails
- }
-}
-```
-
-**Fonction `deleteMissionLogo()` - `lib/mission-uploads.ts`** :
-
-**Lignes 42-61**
-
-```typescript
-export async function deleteMissionLogo(
- missionId: string,
- logoPath: string
-): Promise {
- try {
- const normalizedPath = ensureMissionsPrefix(logoPath);
- // ⚠️ TODO: La fonction ne fait que logger, ne supprime pas vraiment !
- console.log('Deleting mission logo:', {
- missionId,
- originalPath: logoPath,
- normalizedPath
- });
- // TODO: Implémenter la suppression réelle avec DeleteObjectCommand
- } catch (error) {
- console.error('Error deleting mission logo:', error);
- throw error;
- }
-}
-```
-
-**⚠️ PROBLÈME IDENTIFIÉ** :
-- ❌ La fonction `deleteMissionLogo()` ne supprime **PAS** réellement le fichier
-- ❌ Elle ne fait que logger les informations
-- ⚠️ Le logo reste dans Minio après suppression de la mission
-
-**Solution proposée** :
-```typescript
-export async function deleteMissionLogo(
- missionId: string,
- logoPath: string
-): Promise {
- try {
- const { DeleteObjectCommand } = await import('@aws-sdk/client-s3');
- const normalizedPath = ensureMissionsPrefix(logoPath);
- const minioPath = normalizedPath.replace(/^missions\//, '');
-
- await s3Client.send(new DeleteObjectCommand({
- Bucket: 'missions',
- Key: minioPath
- }));
-
- console.log('Mission logo deleted successfully:', minioPath);
- } catch (error) {
- console.error('Error deleting mission logo:', error);
- throw error;
- }
-}
-```
-
-**Points importants** :
-- ✅ Continue la suppression même si le logo échoue (try/catch)
-- ⚠️ **BUG** : Le logo n'est pas réellement supprimé actuellement
-
-### 2.4 STEP 2 : Rollback N8N (TODO - Non Implémenté)
-
-**Lignes 336-344**
-
-```typescript
-// Trigger n8n workflow for rollback
-// TODO: Implement rollbackMission method in N8nService
-// const n8nService = new N8nService();
-// try {
-// await n8nService.rollbackMission(mission);
-// } catch (error) {
-// console.error('Error during mission rollback:', error);
-// // Continue with mission deletion even if rollback fails
-// }
-```
-
-**⚠️ NON IMPLÉMENTÉ** :
-- ❌ Le rollback N8N n'est pas appelé
-- ❌ Les intégrations externes (Leantime, Outline, RocketChat, etc.) ne sont **PAS** supprimées
-- ⚠️ Les ressources externes restent orphelines
-
-**Méthode disponible mais non utilisée** :
-- ✅ `N8nService.triggerMissionRollback()` existe dans `lib/services/n8n-service.ts`
-- ✅ Webhook URL : `https://brain.slm-lab.net/webhook/mission-rollback`
-- ❌ Mais n'est pas appelée dans le DELETE
-
-**Solution proposée** :
-```typescript
-// Rollback N8N
-const n8nService = new N8nService();
-try {
- await n8nService.triggerMissionRollback({
- missionId: mission.id,
- leantimeProjectId: mission.leantimeProjectId,
- outlineCollectionId: mission.outlineCollectionId,
- rocketChatChannelId: mission.rocketChatChannelId,
- giteaRepositoryUrl: mission.giteaRepositoryUrl,
- penpotProjectId: mission.penpotProjectId
- });
-} catch (error) {
- console.error('Error during mission rollback:', error);
- // Continue with mission deletion even if rollback fails
-}
-```
-
-### 2.5 STEP 3 : Suppression de la Mission en Base de Données
-
-**Lignes 346-349**
-
-```typescript
-// Suppression de la mission (CASCADE automatique)
-await prisma.mission.delete({
- where: { id: params.missionId }
-});
-```
-
-**Schéma Prisma - Relations avec CASCADE** :
-
-```prisma
-model Mission {
- // ...
- attachments Attachment[]
- missionUsers MissionUser[]
-}
-
-model Attachment {
- mission Mission @relation(fields: [missionId], references: [id], onDelete: Cascade)
- // ...
-}
-
-model MissionUser {
- mission Mission @relation(fields: [missionId], references: [id], onDelete: Cascade)
- // ...
-}
-```
-
-**CASCADE automatique** :
-- ✅ **MissionUsers** : Supprimés automatiquement (`onDelete: Cascade`)
-- ✅ **Attachments** : Supprimés automatiquement (`onDelete: Cascade`)
-- ❌ **Fichiers Minio** : **NON supprimés automatiquement** (pas de trigger)
-
-**Points importants** :
-- ✅ Une seule requête Prisma supprime la mission et toutes ses relations
-- ✅ Atomicité : Si la suppression échoue, rien n'est supprimé
-- ⚠️ **PROBLÈME** : Les fichiers Minio des attachments ne sont pas supprimés
-
-### 2.6 Retour de Succès
-
-**Lignes 351-358**
-
-```typescript
-return NextResponse.json({ success: true });
-
-} catch (error) {
- console.error('Error deleting mission:', error);
- return NextResponse.json(
- { error: 'Failed to delete mission' },
- { status: 500 }
- );
-}
-```
-
----
-
-## 🔄 ÉTAPE 3 : Cascade Prisma
-
-### Suppression Automatique des Relations
-
-Quand `prisma.mission.delete()` est exécuté, Prisma supprime automatiquement :
-
-1. **Tous les MissionUsers** associés
- ```sql
- DELETE FROM "MissionUser" WHERE "missionId" = 'abc-123';
- ```
-
-2. **Tous les Attachments** associés
- ```sql
- DELETE FROM "Attachment" WHERE "missionId" = 'abc-123';
- ```
-
-**⚠️ PROBLÈME MAJEUR** :
-- ❌ Les fichiers Minio des attachments ne sont **PAS** supprimés
-- ❌ Les fichiers restent dans Minio : `missions/{missionId}/attachments/*`
-- ⚠️ **Orphelins** : Fichiers sans enregistrement en base
-
----
-
-## 🧹 Problèmes Identifiés et Solutions
-
-### Problème 1 : Logo non supprimé dans Minio
-
-**Symptôme** : Le logo reste dans Minio après suppression
-
-**Cause** : `deleteMissionLogo()` ne fait que logger, ne supprime pas
-
-**Solution** :
-```typescript
-export async function deleteMissionLogo(
- missionId: string,
- logoPath: string
-): Promise {
- const { DeleteObjectCommand } = await import('@aws-sdk/client-s3');
- const normalizedPath = ensureMissionsPrefix(logoPath);
- const minioPath = normalizedPath.replace(/^missions\//, '');
-
- await s3Client.send(new DeleteObjectCommand({
- Bucket: 'missions',
- Key: minioPath
- }));
-}
-```
-
-### Problème 2 : Attachments non supprimés dans Minio
-
-**Symptôme** : Les fichiers attachments restent dans Minio
-
-**Cause** : Pas de suppression des fichiers avant la suppression Prisma
-
-**Solution** :
-```typescript
-// Avant la suppression Prisma
-if (mission.attachments && mission.attachments.length > 0) {
- // Récupérer les attachments
- const attachments = await prisma.attachment.findMany({
- where: { missionId: params.missionId }
- });
-
- // Supprimer chaque fichier Minio
- for (const attachment of attachments) {
- try {
- await deleteMissionAttachment(attachment.filePath);
- } catch (error) {
- console.error('Error deleting attachment file:', error);
- // Continue même si un fichier échoue
- }
- }
-}
-```
-
-### Problème 3 : Rollback N8N non implémenté
-
-**Symptôme** : Les intégrations externes restent orphelines
-
-**Cause** : Code commenté, non implémenté
-
-**Solution** :
-```typescript
-// Décommenter et implémenter
-const n8nService = new N8nService();
-try {
- await n8nService.triggerMissionRollback({
- missionId: mission.id,
- leantimeProjectId: mission.leantimeProjectId,
- outlineCollectionId: mission.outlineCollectionId,
- rocketChatChannelId: mission.rocketChatChannelId,
- giteaRepositoryUrl: mission.giteaRepositoryUrl,
- penpotProjectId: mission.penpotProjectId
- });
-} catch (error) {
- console.error('Error during mission rollback:', error);
- // Continue avec la suppression même si rollback échoue
-}
-```
-
----
-
-## 📊 Résumé des Opérations
-
-### Opérations Effectuées ✅
-
-1. ✅ **Vérification authentification** : Session NextAuth
-2. ✅ **Vérification permissions** : Créateur ou Admin
-3. ✅ **Suppression Prisma Mission** : Avec cascade automatique
-4. ✅ **Suppression Prisma MissionUsers** : Cascade automatique
-5. ✅ **Suppression Prisma Attachments** : Cascade automatique
-
-### Opérations NON Effectuées ❌
-
-1. ❌ **Suppression logo Minio** : Fonction ne fait que logger
-2. ❌ **Suppression attachments Minio** : Pas de code pour supprimer
-3. ❌ **Rollback N8N** : Code commenté, non implémenté
-
----
-
-## 🔍 Workflow Complet Corrigé (Proposé)
-
-```typescript
-export async function DELETE(...) {
- // 1. Authentification
- const session = await getServerSession(authOptions);
- if (!session?.user) return 401;
-
- // 2. Récupération mission avec attachments
- const mission = await prisma.mission.findUnique({
- where: { id: params.missionId },
- include: {
- attachments: true, // Inclure les attachments
- missionUsers: true
- }
- });
-
- if (!mission) return 404;
-
- // 3. Vérification permissions
- const isCreator = mission.creatorId === session.user.id;
- const isAdmin = session.user.role?.includes('admin');
- if (!isCreator && !isAdmin) return 403;
-
- // 4. Suppression logo Minio
- if (mission.logo) {
- try {
- await deleteMissionLogo(mission.id, mission.logo); // À implémenter
- } catch (error) {
- console.error('Error deleting logo:', error);
- // Continue
- }
- }
-
- // 5. Suppression attachments Minio
- if (mission.attachments && mission.attachments.length > 0) {
- for (const attachment of mission.attachments) {
- try {
- await deleteMissionAttachment(attachment.filePath);
- } catch (error) {
- console.error('Error deleting attachment:', error);
- // Continue
- }
- }
- }
-
- // 6. Rollback N8N
- const n8nService = new N8nService();
- try {
- await n8nService.triggerMissionRollback({
- missionId: mission.id,
- leantimeProjectId: mission.leantimeProjectId,
- outlineCollectionId: mission.outlineCollectionId,
- rocketChatChannelId: mission.rocketChatChannelId,
- giteaRepositoryUrl: mission.giteaRepositoryUrl,
- penpotProjectId: mission.penpotProjectId
- });
- } catch (error) {
- console.error('Error during N8N rollback:', error);
- // Continue même si rollback échoue
- }
-
- // 7. Suppression Prisma (CASCADE)
- await prisma.mission.delete({
- where: { id: params.missionId }
- });
-
- return NextResponse.json({ success: true });
-}
-```
-
----
-
-## 📈 Ordre d'Exécution Recommandé
-
-1. **Vérifications** (authentification, permissions, existence)
-2. **Suppression fichiers Minio** (logo + attachments)
-3. **Rollback N8N** (intégrations externes)
-4. **Suppression Prisma** (mission + cascade automatique)
-
-**Pourquoi cet ordre ?**
-- ✅ Supprimer les fichiers avant la base pour éviter les orphelins
-- ✅ Rollback N8N avant suppression Prisma pour avoir les IDs
-- ✅ Suppression Prisma en dernier (point de non-retour)
-
----
-
-## ⚠️ Points d'Attention
-
-### 1. Atomicité
-**Problème** : Si une étape échoue, les précédentes sont déjà faites
-
-**Solution** : Transaction Prisma + Rollback manuel si erreur
-
-### 2. Performance
-**Problème** : Suppression séquentielle des fichiers Minio
-
-**Solution** : `Promise.all()` pour suppressions parallèles
-
-### 3. Gestion d'Erreurs
-**Problème** : Continue même si certaines suppressions échouent
-
-**Solution** : Décider si on continue ou on rollback selon criticité
-
----
-
-## 🔍 Debugging
-
-### Logs à surveiller :
-
-1. **Début suppression** : `DELETE /api/missions/[id]`
-2. **Permissions** : `isCreator` / `isAdmin`
-3. **Suppression logo** : `Deleting mission logo`
-4. **Suppression attachments** : `Deleting mission attachment`
-5. **Rollback N8N** : `Triggering n8n rollback workflow`
-6. **Suppression Prisma** : `prisma.mission.delete()`
-
-### Vérifications manuelles :
-
-```bash
-# Vérifier Minio
-# Accéder à https://dome-api.slm-lab.net
-# Bucket: missions
-# Vérifier que les dossiers {missionId} sont supprimés
-
-# Vérifier Prisma
-npx prisma studio
-# Vérifier que la mission et ses relations sont supprimées
-```
-
----
-
-**Document généré le** : $(date)
-**Version** : 1.0
-**Auteur** : Analyse complète du codebase
-
diff --git a/MISSION_INTEGRATION_IDS_FIX.md b/MISSION_INTEGRATION_IDS_FIX.md
deleted file mode 100644
index 0d26fb56..00000000
--- a/MISSION_INTEGRATION_IDS_FIX.md
+++ /dev/null
@@ -1,308 +0,0 @@
-# Fix : Sauvegarde des IDs d'Intégration N8N
-
-## 🔍 Problème Identifié
-
-Lors de la suppression d'une mission, le webhook N8N reçoit des IDs vides :
-
-```json
-{
- "repoName": "",
- "leantimeProjectId": 0,
- "documentationCollectionId": "",
- "rocketchatChannelId": ""
-}
-```
-
-**Cause** : Les IDs retournés par N8N lors de la création des intégrations n'étaient **jamais sauvegardés en base**.
-
-### Workflow Problématique
-
-```
-1. Frontend → POST /api/missions
- ↓
-2. Backend crée mission en Prisma
- ↓
-3. Backend upload fichiers Minio
- ↓
-4. Backend → POST N8N webhook (mission-created)
- ↓
-5. N8N crée intégrations (Gitea, Leantime, Outline, RocketChat)
- ↓
-6. N8N → POST /mission-created ❌ ENDPOINT N'EXISTAIT PAS
- ↓
-7. IDs jamais sauvegardés ❌
-```
-
-### Conséquence
-
-Lors de la suppression :
-- Les IDs sont `null` en base
-- On envoie des valeurs vides à N8N
-- N8N ne peut pas supprimer/fermer les intégrations
-- Les ressources externes restent orphelines
-
----
-
-## ✅ Solution Implémentée
-
-### 1. Endpoint `/mission-created` Créé
-
-**Fichier** : `app/api/missions/mission-created/route.ts`
-
-**Fonctionnalités** :
-- ✅ Reçoit les IDs des intégrations créées par N8N
-- ✅ Vérifie l'API key (`x-api-key` header)
-- ✅ Trouve la mission par `name` + `creatorId`
-- ✅ Met à jour la mission avec les IDs
-- ✅ Mappe correctement les champs :
- - `gitRepoUrl` → `giteaRepositoryUrl`
- - `documentationCollectionId` → `outlineCollectionId`
- - `rocketchatChannelId` → `rocketChatChannelId`
- - `leantimeProjectId` → `leantimeProjectId` (converti en string)
-
-### 2. Format des Données
-
-**N8N envoie** :
-```json
-{
- "name": "Mission Example",
- "creatorId": "user-id",
- "gitRepoUrl": "https://gite.slm-lab.net/alma/mission-example",
- "leantimeProjectId": "123",
- "documentationCollectionId": "collection-456",
- "rocketchatChannelId": "channel-789"
-}
-```
-
-**Endpoint sauvegarde** :
-```typescript
-{
- giteaRepositoryUrl: "https://gite.slm-lab.net/alma/mission-example",
- leantimeProjectId: "123",
- outlineCollectionId: "collection-456",
- rocketChatChannelId: "channel-789"
-}
-```
-
-### 3. Sécurité
-
-- ✅ Vérification de l'API key (`x-api-key` header)
-- ✅ Validation des champs requis (`name`, `creatorId`)
-- ✅ Gestion d'erreurs complète
-- ✅ Logging détaillé pour debugging
-
----
-
-## 🔄 Nouveau Workflow
-
-```
-1. Frontend → POST /api/missions
- ↓
-2. Backend crée mission en Prisma
- ↓
-3. Backend upload fichiers Minio
- ↓
-4. Backend → POST N8N webhook (mission-created)
- ↓
-5. N8N crée intégrations (Gitea, Leantime, Outline, RocketChat)
- ↓
-6. N8N → POST /mission-created ✅ ENDPOINT EXISTE MAINTENANT
- ↓
-7. Backend sauvegarde les IDs ✅
- ↓
-8. Mission complète avec tous les IDs ✅
-```
-
-**Lors de la suppression** :
-```
-1. Frontend → DELETE /api/missions/[id]
- ↓
-2. Backend récupère mission (avec IDs sauvegardés)
- ↓
-3. Backend extrait/mappe les données
- ↓
-4. Backend → POST N8N webhook (mission-delete)
- ↓
-5. N8N reçoit les IDs ✅
- ↓
-6. N8N supprime/ferme les intégrations ✅
-```
-
----
-
-## 📋 Format de Requête
-
-### POST /api/missions/mission-created
-
-**Headers** :
-```
-Content-Type: application/json
-x-api-key: {N8N_API_KEY}
-Authorization: Bearer {keycloak_token} (optionnel)
-```
-
-**Body** :
-```json
-{
- "name": "Mission Example",
- "creatorId": "user-uuid",
- "gitRepoUrl": "https://gite.slm-lab.net/alma/mission-example",
- "leantimeProjectId": "123",
- "documentationCollectionId": "collection-456",
- "rocketchatChannelId": "channel-789",
- "niveau": "default",
- "intention": "...",
- "description": "...",
- "donneurDOrdre": "...",
- "projection": "...",
- "missionType": "remote"
-}
-```
-
-**Réponse Succès** (200) :
-```json
-{
- "success": true,
- "message": "Mission updated successfully",
- "mission": {
- "id": "mission-uuid",
- "name": "Mission Example",
- "giteaRepositoryUrl": "https://gite.slm-lab.net/alma/mission-example",
- "leantimeProjectId": "123",
- "outlineCollectionId": "collection-456",
- "rocketChatChannelId": "channel-789"
- }
-}
-```
-
-**Réponse Erreur** (400/404/500) :
-```json
-{
- "error": "Error message",
- "details": "Detailed error information"
-}
-```
-
----
-
-## ⚠️ Missions Existantes
-
-**Problème** : Les missions créées avant cette correction n'ont pas leurs IDs sauvegardés.
-
-**Solutions possibles** :
-
-### Option 1 : Migration Manuelle
-Pour chaque mission existante, récupérer les IDs depuis les services externes et les mettre à jour manuellement.
-
-### Option 2 : Script de Migration
-Créer un script qui :
-1. Liste toutes les missions sans IDs
-2. Interroge les services externes (si possible)
-3. Met à jour les missions
-
-### Option 3 : Re-création
-Supprimer et recréer les missions (si acceptable).
-
-**Recommandation** : Option 1 pour les missions critiques, Option 2 pour un grand nombre.
-
----
-
-## 🧪 Tests
-
-### Test 1 : Création de Mission
-
-1. Créer une nouvelle mission via le frontend
-2. Vérifier que N8N appelle `/mission-created`
-3. Vérifier que la mission en base a les IDs sauvegardés :
- ```sql
- SELECT id, name, giteaRepositoryUrl, leantimeProjectId,
- outlineCollectionId, rocketChatChannelId
- FROM Mission
- WHERE name = 'Mission Test';
- ```
-
-### Test 2 : Suppression de Mission
-
-1. Supprimer une mission avec IDs sauvegardés
-2. Vérifier que N8N reçoit les IDs :
- ```json
- {
- "repoName": "mission-example",
- "leantimeProjectId": 123,
- "documentationCollectionId": "collection-456",
- "rocketchatChannelId": "channel-789"
- }
- ```
-3. Vérifier que N8N supprime/ferme les intégrations
-
-### Test 3 : API Key
-
-1. Appeler `/mission-created` sans `x-api-key` → 401
-2. Appeler avec mauvais `x-api-key` → 401
-3. Appeler avec bon `x-api-key` → 200
-
----
-
-## 📝 Logs à Surveiller
-
-### Création
-
-```
-=== Mission Created Webhook Received ===
-Received mission-created data: { ... }
-Found mission: { id: "...", name: "..." }
-Updating giteaRepositoryUrl: ...
-Updating leantimeProjectId: ...
-Mission updated successfully: { ... }
-```
-
-### Suppression
-
-```
-=== Starting N8N Deletion Workflow ===
-Extracted repo name from URL: { url: "...", repoName: "..." }
-Sending deletion data to N8N: { ... }
-N8N Deletion Workflow Result: { success: true, ... }
-```
-
----
-
-## 🔧 Configuration Requise
-
-### Variables d'Environnement
-
-```env
-N8N_API_KEY=your-api-key-here
-NEXT_PUBLIC_API_URL=https://hub.slm-lab.net
-```
-
-### N8N Workflow
-
-Le workflow N8N doit appeler :
-- **URL** : `{{ MISSION_API_URL }}/mission-created`
-- **Méthode** : POST
-- **Headers** :
- - `Content-Type: application/json`
- - `x-api-key: {{ N8N_API_KEY }}`
- - `Authorization: Bearer {{ Keycloak Token }}` (optionnel)
-
----
-
-## ✅ Checklist
-
-- [x] Endpoint `/mission-created` créé
-- [x] Vérification API key implémentée
-- [x] Mapping des champs correct
-- [x] Gestion d'erreurs complète
-- [x] Logging détaillé
-- [ ] Tests manuels effectués
-- [ ] Migration des missions existantes (si nécessaire)
-- [ ] Documentation N8N mise à jour
-
----
-
-**Date de correction** : $(date)
-**Version** : 1.0
-**Fichiers modifiés** :
-- `app/api/missions/mission-created/route.ts` (nouveau)
-
diff --git a/MISSION_INTEGRATION_IDS_ISSUE_FIX.md b/MISSION_INTEGRATION_IDS_ISSUE_FIX.md
deleted file mode 100644
index 4233dc4e..00000000
--- a/MISSION_INTEGRATION_IDS_ISSUE_FIX.md
+++ /dev/null
@@ -1,253 +0,0 @@
-# Fix: IDs d'Intégration Vides lors de la Suppression
-
-## 🔍 Problème Identifié
-
-Lors de la suppression d'une mission, N8N reçoit des IDs vides :
-
-```json
-{
- "missionId": "cd0225cf-8dfd-4bf0-a20a-6aa9c04ebb42",
- "name": "Creation",
- "repoName": "",
- "leantimeProjectId": 0,
- "documentationCollectionId": "",
- "rocketchatChannelId": "",
- "giteaRepositoryUrl": null,
- "outlineCollectionId": null,
- "rocketChatChannelId": null
-}
-```
-
-**Cause** : Les IDs retournés par N8N lors de la création ne sont **pas sauvegardés en base**.
-
----
-
-## 🔍 Analyse du Problème
-
-### Flow Actuel
-
-```
-1. POST /api/missions → Crée mission en Prisma
-2. Upload logo dans Minio
-3. POST N8N webhook → N8N crée intégrations
-4. N8N → POST /mission-created (avec IDs)
-5. ❌ Endpoint cherche mission par name + creatorId (peut échouer)
-6. ❌ IDs jamais sauvegardés
-7. ❌ Lors de suppression → IDs vides
-```
-
-### Problèmes Identifiés
-
-1. **Recherche de mission fragile** : L'endpoint `/mission-created` cherche par `name` + `creatorId`, ce qui peut échouer si :
- - Plusieurs missions ont le même nom
- - Le nom a changé
- - Le creatorId ne correspond pas exactement
-
-2. **missionId non envoyé** : On n'envoie pas le `missionId` à N8N, donc N8N ne peut pas le renvoyer
-
-3. **N8N ne renvoie peut-être pas missionId** : Même si on l'envoie, N8N doit le renvoyer dans `/mission-created`
-
----
-
-## ✅ Solutions Implémentées
-
-### 1. Envoyer missionId à N8N
-
-**Fichier** : `app/api/missions/route.ts`
-
-```typescript
-const n8nData = {
- ...body,
- missionId: mission.id, // ✅ Send missionId so N8N can return it
- creatorId: userId,
- logoPath: logoPath,
- logoUrl: logoUrl,
- config: { ... }
-};
-```
-
-**Avantage** : N8N peut maintenant renvoyer le `missionId` dans `/mission-created`
-
-### 2. Améliorer la Recherche de Mission
-
-**Fichier** : `app/api/missions/mission-created/route.ts`
-
-```typescript
-// Prefer missionId if provided, otherwise use name + creatorId
-let mission;
-
-if (body.missionId) {
- // ✅ Use missionId if provided (more reliable)
- mission = await prisma.mission.findUnique({
- where: { id: body.missionId }
- });
-} else if (body.name && body.creatorId) {
- // Fallback to name + creatorId (for backward compatibility)
- mission = await prisma.mission.findFirst({
- where: {
- name: body.name,
- creatorId: body.creatorId
- },
- orderBy: { createdAt: 'desc' }
- });
-}
-```
-
-**Avantages** :
-- ✅ Recherche par `missionId` (plus fiable)
-- ✅ Fallback vers `name` + `creatorId` (rétrocompatibilité)
-- ✅ Gestion d'erreurs améliorée
-
----
-
-## 📋 Format de Requête N8N → /mission-created
-
-### Format Recommandé (avec missionId)
-
-```json
-{
- "missionId": "cd0225cf-8dfd-4bf0-a20a-6aa9c04ebb42",
- "name": "Creation",
- "creatorId": "user-id",
- "gitRepoUrl": "https://gite.slm-lab.net/alma/creation",
- "leantimeProjectId": "123",
- "documentationCollectionId": "collection-456",
- "rocketchatChannelId": "channel-789"
-}
-```
-
-### Format de Fallback (sans missionId)
-
-```json
-{
- "name": "Creation",
- "creatorId": "user-id",
- "gitRepoUrl": "https://gite.slm-lab.net/alma/creation",
- "leantimeProjectId": "123",
- "documentationCollectionId": "collection-456",
- "rocketchatChannelId": "channel-789"
-}
-```
-
----
-
-## 🔧 Action Requise dans N8N
-
-### Modifier le Node "Save Mission To API"
-
-Le node N8N doit inclure `missionId` dans le body :
-
-**Avant** :
-```json
-{
- "name": "{{ name }}",
- "creatorId": "{{ creatorId }}",
- "gitRepoUrl": "{{ gitRepo.html_url }}",
- ...
-}
-```
-
-**Après** :
-```json
-{
- "missionId": "{{ missionId }}", // ✅ Ajouter missionId
- "name": "{{ name }}",
- "creatorId": "{{ creatorId }}",
- "gitRepoUrl": "{{ gitRepo.html_url }}",
- "leantimeProjectId": "{{ leantimeProject.result[0] }}",
- "documentationCollectionId": "{{ docCollection.data.id }}",
- "rocketchatChannelId": "{{ rocketChatChannel.channel._id }}",
- ...
-}
-```
-
-**Où trouver missionId dans N8N** :
-- Il est dans les données initiales : `{{ $node['Process Mission Data'].json.missionId }}`
-- Ou dans le body original : `{{ $json.missionId }}`
-
----
-
-## 🧪 Tests
-
-### Test 1: Vérifier missionId est envoyé à N8N
-
-1. Créer une mission
-2. Vérifier les logs :
- ```
- Sending to N8N: { missionId: "...", ... }
- ```
-3. ✅ `missionId` doit être présent
-
-### Test 2: Vérifier N8N renvoie missionId
-
-1. Vérifier les logs N8N
-2. Vérifier que le node "Save Mission To API" inclut `missionId`
-3. ✅ `missionId` doit être dans le body envoyé à `/mission-created`
-
-### Test 3: Vérifier IDs sont sauvegardés
-
-1. Créer une mission
-2. Vérifier les logs :
- ```
- === Mission Created Webhook Received ===
- Looking up mission by ID: ...
- Mission updated successfully: { ... }
- ```
-3. Vérifier en base :
- ```sql
- SELECT id, name, giteaRepositoryUrl, leantimeProjectId,
- outlineCollectionId, rocketChatChannelId
- FROM Mission
- WHERE id = '...';
- ```
-4. ✅ Les IDs doivent être présents
-
-### Test 4: Vérifier Suppression
-
-1. Supprimer une mission avec IDs sauvegardés
-2. Vérifier les logs :
- ```
- Sending deletion data to N8N: {
- repoName: "creation",
- leantimeProjectId: 123,
- ...
- }
- ```
-3. ✅ Les IDs doivent être présents (pas vides)
-
----
-
-## 📝 Checklist
-
-- [x] Envoyer `missionId` à N8N lors de la création
-- [x] Améliorer recherche de mission dans `/mission-created`
-- [ ] **Modifier N8N workflow pour inclure `missionId` dans `/mission-created`**
-- [ ] Tester création avec `missionId`
-- [ ] Tester sauvegarde des IDs
-- [ ] Tester suppression avec IDs sauvegardés
-
----
-
-## ⚠️ Action Immédiate Requise
-
-**Modifier le workflow N8N** pour inclure `missionId` dans le node "Save Mission To API" :
-
-1. Ouvrir le workflow N8N `NeahMissionCreate`
-2. Trouver le node "Save Mission To API"
-3. Ajouter `missionId` dans le body :
- ```json
- {
- "missionId": "={{ $node['Process Mission Data'].json.missionId }}",
- ...
- }
- ```
-4. Sauvegarder et activer le workflow
-
----
-
-**Date**: $(date)
-**Version**: 1.1
-**Fichiers Modifiés**:
-- `app/api/missions/route.ts` (ajout missionId dans n8nData)
-- `app/api/missions/mission-created/route.ts` (recherche par missionId)
-
diff --git a/N8N_COMPLETE_WORKFLOW_MAPPING.md b/N8N_COMPLETE_WORKFLOW_MAPPING.md
deleted file mode 100644
index cfddacb6..00000000
--- a/N8N_COMPLETE_WORKFLOW_MAPPING.md
+++ /dev/null
@@ -1,673 +0,0 @@
-# Mapping Complet N8N - Création et Suppression de Mission
-
-## 📋 Vue d'Ensemble
-
-Ce document décrit le mapping complet entre notre API et les workflows N8N pour la création et la suppression de missions, basé sur les workflows réels partagés.
-
----
-
-## 🔄 Workflow de Création - NeahMissionCreate
-
-### Structure du Workflow
-
-```
-Webhook (mission-created)
- ↓
-Process Mission Data
- ↓
-Get Keycloak Token
- ↓
-Process Token
- ↓
-Debug Service Data
- ↓
-Merge Paths
- ↓
-IF Run Integrations
- ├─ IF Needs Git Repository
- │ ├─ Create Git Repository (si Gite ou Calcul)
- │ ├─ Create Readme
- │ └─ Git Wiki
- ├─ Create Documentation Collection
- ├─ Create Leantime Project
- │ └─ Leantime Avatar
- └─ Create RocketChat Channel
- ↓
-Combine Results
- ↓
-Save Mission To API (POST /mission-created)
- ↓
-Process Results
- ↓
-Respond To Webhook
-```
-
-### Données Envoyées par Notre API → N8N
-
-**Endpoint** : `POST https://brain.slm-lab.net/webhook/mission-created`
-
-**Format** :
-```typescript
-{
- name: string,
- oddScope: string[],
- niveau: string,
- intention: string,
- missionType: string,
- donneurDOrdre: string,
- projection: string,
- services: string[],
- participation: string,
- profils: string[],
- guardians: {
- "gardien-temps": userId,
- "gardien-parole": userId,
- "gardien-memoire": userId
- },
- volunteers: string[],
- creatorId: string,
- logo: {
- data: "data:image/png;base64,...",
- name: string,
- type: string
- },
- attachments: Array<{
- data: "data:...;base64,...",
- name: string,
- type: string
- }>,
- config: {
- N8N_API_KEY: string,
- MISSION_API_URL: string
- }
-}
-```
-
-### Traitement N8N - Process Mission Data
-
-Le node "Process Mission Data" transforme les données en :
-
-```javascript
-{
- missionOriginal: { ... }, // Données originales
- missionProcessed: {
- name: "Mission Example",
- sanitizedName: "mission-example", // Nom nettoyé pour URLs
- intention: "...",
- description: "...",
- startDate: "2024-01-01",
- endDate: "2024-01-31",
- missionType: "remote",
- guardians: { ... },
- volunteers: [ ... ],
- profils: [ ... ],
- services: ["Gite", "ArtLab"], // Détermine quelles intégrations créer
- clientId: 2,
- rocketChatUsernames: [userId1, userId2, ...], // Gardiens + volontaires
- logo: { data: "...", name: "...", type: "..." },
- attachments: [ ... ]
- },
- config: {
- GITEA_API_URL: "https://gite.slm-lab.net/api/v1",
- GITEA_API_TOKEN: "...",
- GITEA_OWNER: "alma",
- LEANTIME_API_URL: "https://agilite.slm-lab.net",
- LEANTIME_API_TOKEN: "...",
- ROCKETCHAT_API_URL: "https://parole.slm-lab.net/",
- ROCKETCHAT_AUTH_TOKEN: "...",
- ROCKETCHAT_USER_ID: "...",
- OUTLINE_API_URL: "https://chapitre.slm-lab.net/api",
- OUTLINE_API_TOKEN: "...",
- MISSION_API_URL: "https://hub.slm-lab.net",
- // ... autres configs
- },
- creatorId: "user-id"
-}
-```
-
-### Intégrations Créées par N8N
-
-#### 1. Gitea Repository (Conditionnel)
-
-**Condition** : `services.includes('Gite') || services.includes('Calcul')`
-
-**Node** : "Create Git Repository"
-- **Méthode** : POST
-- **URL** : `{{ GITEA_API_URL }}/user/repos`
-- **Body** :
- ```json
- {
- "name": "{{ sanitizedName }}",
- "private": true,
- "auto_init": true,
- "avatar_url": "{{ logo.data }}"
- }
- ```
-- **Résultat** : `{ html_url: "https://gite.slm-lab.net/alma/mission-example" }`
-
-**Actions supplémentaires** :
-- Create Readme : Crée un document README dans Outline
-- Git Wiki : Configure le wiki externe du repo vers Outline
-
-#### 2. Leantime Project
-
-**Node** : "Create Leantime Project"
-- **Méthode** : POST
-- **URL** : `{{ LEANTIME_API_URL }}/api/jsonrpc`
-- **Body** :
- ```json
- {
- "method": "leantime.rpc.Projects.Projects.addProject",
- "jsonrpc": "2.0",
- "id": 1,
- "params": {
- "values": {
- "name": "{{ name }}",
- "clientId": {{ clientId }},
- "details": "{{ intention }}",
- "type": "project",
- "start": "{{ startDate }}",
- "end": "{{ endDate }}",
- "status": "open",
- "psettings": "restricted",
- "avatar": "{{ logo.data }}"
- }
- }
- }
- ```
-- **Résultat** : `{ result: [projectId] }` (array avec 1 élément)
-
-**Action supplémentaire** :
-- Leantime Avatar : Met à jour l'avatar du projet
-
-#### 3. Outline Collection
-
-**Node** : "Create Documentation Collection"
-- **Méthode** : POST
-- **URL** : `{{ OUTLINE_API_URL }}/api/collections.create`
-- **Body** :
- ```json
- {
- "name": "{{ sanitizedName }}",
- "description": "{{ description }}",
- "permission": "read",
- "private": true
- }
- ```
-- **Résultat** : `{ data: { id: "collection-id", url: "/collection/..." } }`
-
-#### 4. RocketChat Channel
-
-**Node** : "Create RocketChat Channel"
-- **Méthode** : POST
-- **URL** : `{{ ROCKETCHAT_API_URL }}/api/v1/channels.create`
-- **Body** :
- ```json
- {
- "name": "{{ sanitizedName }}",
- "members": [{{ rocketChatUsernames }}],
- "readOnly": false,
- "avatarUrl": "{{ logo.data }}"
- }
- ```
-- **Résultat** : `{ channel: { _id: "channel-id", ... } }`
-
-### Save Mission To API - Retour vers Notre API
-
-**Node** : "Save Mission To API"
-- **Méthode** : POST
-- **URL** : `{{ MISSION_API_URL }}/mission-created`
-- **Headers** :
- - `Content-Type: application/json`
- - `Authorization: Bearer {{ Keycloak Token }}`
- - `x-api-key: {{ N8N_API_KEY }}`
-- **Body** :
- ```json
- {
- "name": "{{ name }}",
- "niveau": "{{ niveau }}",
- "intention": "{{ intention }}",
- "description": "{{ description }}",
- "gitRepoUrl": "{{ gitRepo.html_url }}",
- "leantimeProjectId": "{{ leantimeProject.result[0] }}",
- "documentationCollectionId": "{{ docCollection.data.id }}",
- "rocketchatChannelId": "{{ rocketChatChannel.channel._id }}",
- "donneurDOrdre": "{{ donneurDOrdre }}",
- "projection": "{{ projection }}",
- "missionType": "{{ missionType }}",
- "creatorId": "{{ creatorId }}"
- }
- ```
-
-**⚠️ IMPORTANT** : Cet endpoint `/mission-created` n'existe **PAS** actuellement dans notre codebase. Il devrait :
-1. Recevoir les IDs des intégrations créées
-2. Mettre à jour la mission en base avec ces IDs
-3. Mapper les champs :
- - `gitRepoUrl` → `giteaRepositoryUrl`
- - `documentationCollectionId` → `outlineCollectionId`
- - `rocketchatChannelId` → `rocketChatChannelId`
-
----
-
-## 🗑️ Workflow de Suppression - NeahMissionDelete_Pro
-
-### Structure du Workflow
-
-```
-Webhook Delete (mission-delete)
- ↓
-Process Delete Data
- ↓
-Get Keycloak Token
- ↓
-[En parallèle]
- ├─ Delete Gitea Repo
- ├─ Close Leantime Project
- ├─ Delete Outline Collection
- └─ Close RocketChat Channel
- ↓
-Combine Results
- ↓
-Save Deletion To API (POST /mission-deleted)
-```
-
-### Données Envoyées par Notre API → N8N
-
-**Endpoint** : `POST https://brain.slm-lab.net/webhook-test/mission-delete`
-
-**Format** :
-```typescript
-{
- missionId: string,
- name: string,
- repoName: string, // ✅ Extrait de giteaRepositoryUrl
- leantimeProjectId: number | 0, // ✅ Converti en number
- documentationCollectionId: string, // ✅ Mappé depuis outlineCollectionId
- rocketchatChannelId: string, // ✅ Mappé depuis rocketChatChannelId
- // Champs originaux pour référence
- giteaRepositoryUrl: string | null,
- outlineCollectionId: string | null,
- rocketChatChannelId: string | null,
- penpotProjectId: string | null,
- config: {
- N8N_API_KEY: string,
- MISSION_API_URL: string
- }
-}
-```
-
-### Traitement N8N - Process Delete Data
-
-Le node "Process Delete Data" transforme les données en :
-
-```javascript
-{
- missionData: {
- repoName: input.repoName || '',
- leantimeId: input.leantimeProjectId || 0,
- collectionId: input.documentationCollectionId || '',
- rocketChatRoomId: input.rocketchatChannelId || ''
- },
- config: {
- GITEA_API_URL: "https://gite.slm-lab.net/api/v1",
- GITEA_API_TOKEN: "...",
- GITEA_OWNER: "alma",
- LEANTIME_API_URL: "https://agilite.slm-lab.net",
- LEANTIME_API_TOKEN: "...",
- ROCKETCHAT_API_URL: "https://parole.slm-lab.net/",
- ROCKETCHAT_AUTH_TOKEN: "...",
- ROCKETCHAT_USER_ID: "...",
- OUTLINE_API_URL: "https://chapitre.slm-lab.net/api",
- OUTLINE_API_TOKEN: "...",
- MISSION_API_URL: "https://hub.slm-lab.net",
- KEYCLOAK_BASE_URL: "https://connect.slm-lab.net",
- KEYCLOAK_REALM: "cercle",
- KEYCLOAK_CLIENT_ID: "lab",
- KEYCLOAK_CLIENT_SECRET: "..."
- }
-}
-```
-
-### Actions de Suppression N8N
-
-#### 1. Delete Gitea Repo
-
-**Node** : "Delete Gitea Repo"
-- **Méthode** : DELETE
-- **URL** : `{{ GITEA_API_URL }}/repos/{{ GITEA_OWNER }}/{{ repoName }}`
-- **Headers** : `Authorization: token {{ GITEA_API_TOKEN }}`
-- **ContinueOnFail** : `true`
-- **Résultat attendu** : Status 204 = succès
-
-#### 2. Close Leantime Project
-
-**Node** : "Close Leantime Project"
-- **Méthode** : POST
-- **URL** : `{{ LEANTIME_API_URL }}/api/jsonrpc`
-- **Body** :
- ```json
- {
- "method": "leantime.rpc.Projects.Projects.patch",
- "jsonrpc": "2.0",
- "id": 1,
- "params": {
- "id": {{ leantimeId }},
- "params": { "status": "closed" }
- }
- }
- ```
-- **ContinueOnFail** : `true`
-- **Note** : Le projet est **fermé** (status: "closed"), pas supprimé
-
-#### 3. Delete Outline Collection
-
-**Node** : "Delete Outline Collection"
-- **Méthode** : POST
-- **URL** : `{{ OUTLINE_API_URL }}/api/collections.delete`
-- **Body** : `{ "id": "{{ collectionId }}" }`
-- **ContinueOnFail** : `true`
-- **Résultat attendu** : Status 200 = succès
-
-#### 4. Close RocketChat Channel
-
-**Node** : "Close RocketChat Channel"
-- **Méthode** : POST
-- **URL** : `{{ ROCKETCHAT_API_URL }}/api/v1/channels.close`
-- **Body** : `{ "roomId": "{{ rocketChatRoomId }}" }`
-- **ContinueOnFail** : `true`
-- **Note** : Le canal est **fermé**, pas supprimé
-
-### Combine Results
-
-Le node "Combine Results" combine les résultats :
-
-```javascript
-{
- status: "deleted",
- timestamp: "2024-01-01T12:00:00.000Z",
- details: {
- gitea: true || "already_deleted",
- leantime: true || false,
- outline: true || false,
- rocketchat: true || false
- }
-}
-```
-
-### Save Deletion To API - Retour vers Notre API
-
-**Node** : "Save Deletion To API"
-- **Méthode** : POST
-- **URL** : `{{ MISSION_API_URL }}/mission-deleted`
-- **Headers** :
- - `Authorization: Bearer {{ Keycloak Token }}`
-- **Body** :
- ```json
- {
- "status": "archived",
- "results": {
- "gitea": true,
- "leantime": true,
- "outline": true,
- "rocketchat": true
- }
- }
- ```
-
-**⚠️ IMPORTANT** : Cet endpoint `/mission-deleted` n'existe **PAS** actuellement dans notre codebase. Il pourrait servir à :
-1. Confirmer la suppression
-2. Logger les résultats
-3. Nettoyer des données supplémentaires si nécessaire
-
----
-
-## 📊 Mapping Complet des Champs
-
-### Création (Notre API → N8N → Retour)
-
-| Notre Base | Envoyé à N8N | N8N Crée | Retour N8N | Stocké en Base |
-|-----------|--------------|----------|------------|----------------|
-| - | `name` | - | `name` | `name` |
-| - | `services` | Détermine intégrations | - | `services` |
-| - | `logo.data` | Avatar/Logo | - | `logo` (path) |
-| - | - | Gitea Repo | `gitRepoUrl` | `giteaRepositoryUrl` |
-| - | - | Leantime Project | `leantimeProjectId` | `leantimeProjectId` |
-| - | - | Outline Collection | `documentationCollectionId` | `outlineCollectionId` |
-| - | - | RocketChat Channel | `rocketchatChannelId` | `rocketChatChannelId` |
-
-### Suppression (Notre Base → N8N)
-
-| Notre Base | Extrait/Transformé | Envoyé à N8N | N8N Attend |
-|-----------|-------------------|--------------|------------|
-| `giteaRepositoryUrl` | Extraction nom | `repoName` | `repoName` |
-| `leantimeProjectId` | Converti en number | `leantimeProjectId` | `leantimeId` |
-| `outlineCollectionId` | Direct | `documentationCollectionId` | `collectionId` |
-| `rocketChatChannelId` | Direct | `rocketchatChannelId` | `rocketChatRoomId` |
-
----
-
-## 🔧 Transformations Clés
-
-### 1. Extraction du Nom du Repository Gitea
-
-**Problème** : Notre base stocke l'URL complète, N8N attend le nom seul
-
-**Solution** :
-```typescript
-// Format: https://gite.slm-lab.net/alma/mission-example
-// ou: https://gite.slm-lab.net/api/v1/repos/alma/mission-example
-
-let repoName = '';
-if (giteaRepositoryUrl) {
- try {
- const url = new URL(giteaRepositoryUrl);
- const pathParts = url.pathname.split('/').filter(Boolean);
- repoName = pathParts[pathParts.length - 1] || '';
- } catch (error) {
- const match = giteaRepositoryUrl.match(/\/([^\/]+)\/?$/);
- repoName = match ? match[1] : '';
- }
-}
-```
-
-### 2. Mapping des Champs
-
-**Création** :
-- N8N retourne `gitRepoUrl` → On stocke `giteaRepositoryUrl`
-- N8N retourne `documentationCollectionId` → On stocke `outlineCollectionId`
-- N8N retourne `rocketchatChannelId` → On stocke `rocketChatChannelId`
-
-**Suppression** :
-- On stocke `giteaRepositoryUrl` → On envoie `repoName` (extrait)
-- On stocke `outlineCollectionId` → On envoie `documentationCollectionId`
-- On stocke `rocketChatChannelId` → On envoie `rocketchatChannelId`
-
-### 3. Conversion de Types
-
-**Leantime Project ID** :
-- Stocké en base : `string | null`
-- Envoyé à N8N : `number | 0` (converti)
-- N8N attend : `number` (dans `leantimeId`)
-
----
-
-## ⚠️ Endpoints Manquants
-
-### 1. POST /mission-created
-
-**Rôle** : Recevoir les IDs des intégrations créées par N8N
-
-**Format attendu** :
-```typescript
-POST /mission-created
-Headers: {
- Authorization: "Bearer {keycloak_token}",
- x-api-key: "{N8N_API_KEY}"
-}
-Body: {
- name: string,
- niveau: string,
- intention: string,
- description: string,
- gitRepoUrl: string, // À mapper vers giteaRepositoryUrl
- leantimeProjectId: string, // À mapper vers leantimeProjectId
- documentationCollectionId: string, // À mapper vers outlineCollectionId
- rocketchatChannelId: string, // À mapper vers rocketChatChannelId
- donneurDOrdre: string,
- projection: string,
- missionType: string,
- creatorId: string
-}
-```
-
-**Action requise** :
-1. Trouver la mission par `name` + `creatorId`
-2. Mettre à jour avec les IDs retournés
-3. Mapper les champs correctement
-
-### 2. POST /mission-deleted
-
-**Rôle** : Confirmer la suppression (optionnel)
-
-**Format attendu** :
-```typescript
-POST /mission-deleted
-Headers: {
- Authorization: "Bearer {keycloak_token}"
-}
-Body: {
- status: "archived",
- results: {
- gitea: boolean,
- leantime: boolean,
- outline: boolean,
- rocketchat: boolean
- }
-}
-```
-
-**Action requise** :
-- Logger les résultats
-- Potentiellement nettoyer des données supplémentaires
-
----
-
-## 🔄 Flow Complet - Vue d'Ensemble
-
-### Création
-
-```
-1. Frontend → POST /api/missions
- ↓
-2. Backend crée mission en Prisma
- ↓
-3. Backend upload fichiers Minio
- ↓
-4. Backend → POST N8N webhook (mission-created)
- ↓
-5. N8N crée intégrations (Gitea, Leantime, Outline, RocketChat)
- ↓
-6. N8N → POST /mission-created (⚠️ endpoint manquant)
- ↓
-7. Backend met à jour mission avec IDs (⚠️ non implémenté)
-```
-
-### Suppression
-
-```
-1. Frontend → DELETE /api/missions/[id]
- ↓
-2. Backend récupère mission
- ↓
-3. Backend extrait/mappe les données
- ↓
-4. Backend → POST N8N webhook (mission-delete)
- ↓
-5. N8N supprime/ferme intégrations
- ↓
-6. N8N → POST /mission-deleted (⚠️ endpoint manquant)
- ↓
-7. Backend supprime logo Minio
- ↓
-8. Backend supprime attachments Minio
- ↓
-9. Backend supprime mission Prisma (CASCADE)
-```
-
----
-
-## 📝 Notes Importantes
-
-### 1. Noms de Champs Incohérents
-
-- **Création** : N8N retourne `gitRepoUrl`, `documentationCollectionId`, `rocketchatChannelId`
-- **Suppression** : N8N attend `repoName`, `documentationCollectionId`, `rocketchatChannelId`
-- **Notre Base** : Stocke `giteaRepositoryUrl`, `outlineCollectionId`, `rocketChatChannelId`
-
-**Solution** : Mapping cohérent dans les deux sens
-
-### 2. Endpoint /mission-created Manquant
-
-Actuellement, les IDs retournés par N8N ne sont **PAS** sauvegardés en base. Il faudrait :
-- Créer l'endpoint `/mission-created`
-- Trouver la mission (par `name` + `creatorId` ou `missionId`)
-- Mettre à jour avec les IDs
-
-### 3. Services Conditionnels
-
-- **Gitea** : Créé seulement si `services.includes('Gite') || services.includes('Calcul')`
-- **Leantime** : Toujours créé
-- **Outline** : Toujours créé
-- **RocketChat** : Toujours créé
-
-### 4. Gestion d'Erreurs
-
-- Tous les nodes N8N ont `continueOnFail: true`
-- Les erreurs sont loggées mais n'arrêtent pas le workflow
-- Les résultats indiquent quelles intégrations ont réussi/échoué
-
----
-
-## 🔍 Points de Debugging
-
-### Création
-
-1. **Vérifier données envoyées à N8N** :
- ```
- Sending to N8N: { ... }
- ```
-
-2. **Vérifier réponse N8N** :
- ```
- N8N Workflow Result: { success: true, results: {...} }
- ```
-
-3. **Vérifier endpoint /mission-created** :
- - Doit recevoir les IDs
- - Doit mettre à jour la mission
-
-### Suppression
-
-1. **Vérifier extraction repoName** :
- ```
- Extracted repo name from URL: { url: "...", repoName: "..." }
- ```
-
-2. **Vérifier données envoyées à N8N** :
- ```
- Sending deletion data to N8N: { ... }
- ```
-
-3. **Vérifier réponse N8N** :
- ```
- N8N Deletion Workflow Result: { success: true, results: {...} }
- ```
-
----
-
-**Document généré le** : $(date)
-**Version** : 1.0
-**Workflows N8N** :
-- NeahMissionCreate (création)
-- NeahMissionDelete_Pro (suppression)
-
diff --git a/N8N_DELETION_WORKFLOW_MAPPING.md b/N8N_DELETION_WORKFLOW_MAPPING.md
deleted file mode 100644
index f7c21f2d..00000000
--- a/N8N_DELETION_WORKFLOW_MAPPING.md
+++ /dev/null
@@ -1,342 +0,0 @@
-# Mapping N8N Workflow - Mission Deletion
-
-## 📋 Vue d'Ensemble
-
-Ce document décrit le mapping entre les données de notre API et le format attendu par le workflow N8N `NeahMissionDelete_Pro`.
-
----
-
-## 🔄 Workflow N8N - Structure
-
-### Nodes du Workflow
-
-1. **Webhook Delete** : Reçoit POST sur `/mission-delete`
-2. **Process Delete Data** : Transforme les données d'entrée
-3. **Get Keycloak Token** : Obtient un token d'authentification
-4. **Delete Gitea Repo** : Supprime le repository Gitea (continueOnFail: true)
-5. **Close Leantime Project** : Ferme le projet Leantime (continueOnFail: true)
-6. **Delete Outline Collection** : Supprime la collection Outline (continueOnFail: true)
-7. **Close RocketChat Channel** : Ferme le canal RocketChat (continueOnFail: true)
-8. **Combine Results** : Combine les résultats de toutes les suppressions
-9. **Save Deletion To API** : Envoie les résultats à l'API
-
----
-
-## 📊 Mapping des Données
-
-### Données Envoyées par Notre API
-
-```typescript
-{
- missionId: string,
- name: string,
- repoName: string, // Extrait de giteaRepositoryUrl
- leantimeProjectId: number | null,
- documentationCollectionId: string, // Mappé depuis outlineCollectionId
- rocketchatChannelId: string, // Mappé depuis rocketChatChannelId
- // Champs originaux conservés pour référence
- giteaRepositoryUrl: string | null,
- outlineCollectionId: string | null,
- rocketChatChannelId: string | null,
- penpotProjectId: string | null,
- config: {
- N8N_API_KEY: string,
- MISSION_API_URL: string
- }
-}
-```
-
-### Données Attendues par N8N (Process Delete Data)
-
-Le node "Process Delete Data" transforme les données en :
-
-```javascript
-{
- missionData: {
- repoName: input.repoName || '',
- leantimeId: input.leantimeProjectId || 0,
- collectionId: input.documentationCollectionId || '',
- rocketChatRoomId: input.rocketchatChannelId || ''
- },
- config: {
- GITEA_API_URL: "https://gite.slm-lab.net/api/v1",
- GITEA_API_TOKEN: "...",
- GITEA_OWNER: "alma",
- LEANTIME_API_URL: "https://agilite.slm-lab.net",
- LEANTIME_API_TOKEN: "...",
- ROCKETCHAT_API_URL: "https://parole.slm-lab.net/",
- ROCKETCHAT_AUTH_TOKEN: "...",
- ROCKETCHAT_USER_ID: "...",
- OUTLINE_API_URL: "https://chapitre.slm-lab.net/api",
- OUTLINE_API_TOKEN: "...",
- MISSION_API_URL: "https://hub.slm-lab.net",
- KEYCLOAK_BASE_URL: "https://connect.slm-lab.net",
- KEYCLOAK_REALM: "cercle",
- KEYCLOAK_CLIENT_ID: "lab",
- KEYCLOAK_CLIENT_SECRET: "..."
- }
-}
-```
-
----
-
-## 🔧 Transformations Effectuées
-
-### 1. Extraction du Nom du Repository Gitea
-
-**Problème** : Notre base stocke `giteaRepositoryUrl` (URL complète), mais N8N attend `repoName` (nom seul)
-
-**Solution** : Extraction du nom depuis l'URL
-
-```typescript
-// Format possible:
-// - https://gite.slm-lab.net/alma/repo-name
-// - https://gite.slm-lab.net/api/v1/repos/alma/repo-name
-
-let repoName = '';
-if (mission.giteaRepositoryUrl) {
- try {
- const url = new URL(mission.giteaRepositoryUrl);
- const pathParts = url.pathname.split('/').filter(Boolean);
- repoName = pathParts[pathParts.length - 1] || '';
- } catch (error) {
- // Fallback: extraction regex
- const match = mission.giteaRepositoryUrl.match(/\/([^\/]+)\/?$/);
- repoName = match ? match[1] : '';
- }
-}
-```
-
-**Exemples** :
-- `https://gite.slm-lab.net/alma/mission-abc` → `mission-abc`
-- `https://gite.slm-lab.net/api/v1/repos/alma/mission-xyz` → `mission-xyz`
-
-### 2. Mapping des Champs
-
-| Notre Base de Données | N8N Attend | Transformation |
-|----------------------|------------|----------------|
-| `giteaRepositoryUrl` | `repoName` | Extraction du nom depuis URL |
-| `leantimeProjectId` | `leantimeProjectId` | Direct (converti en number) |
-| `outlineCollectionId` | `documentationCollectionId` | Direct mapping |
-| `rocketChatChannelId` | `rocketchatChannelId` | Direct mapping (lowercase 'c') |
-
----
-
-## 🎯 Actions N8N par Service
-
-### 1. Gitea Repository
-
-**Node** : "Delete Gitea Repo"
-- **Méthode** : DELETE
-- **URL** : `{{ GITEA_API_URL }}/repos/{{ GITEA_OWNER }}/{{ repoName }}`
-- **Headers** : `Authorization: token {{ GITEA_API_TOKEN }}`
-- **ContinueOnFail** : `true` (continue même si échoue)
-
-**Résultat attendu** : Status 204 (No Content) = succès
-
-### 2. Leantime Project
-
-**Node** : "Close Leantime Project"
-- **Méthode** : POST
-- **URL** : `{{ LEANTIME_API_URL }}/api/jsonrpc`
-- **Headers** : `X-API-Key: {{ LEANTIME_API_TOKEN }}`
-- **Body** :
- ```json
- {
- "method": "leantime.rpc.Projects.Projects.patch",
- "jsonrpc": "2.0",
- "id": 1,
- "params": {
- "id": {{ leantimeId }},
- "params": { "status": "closed" }
- }
- }
- ```
-- **ContinueOnFail** : `true`
-
-**Note** : Le projet est **fermé** (status: "closed"), pas supprimé
-
-### 3. Outline Collection
-
-**Node** : "Delete Outline Collection"
-- **Méthode** : POST
-- **URL** : `{{ OUTLINE_API_URL }}/api/collections.delete`
-- **Headers** : `Authorization: Bearer {{ OUTLINE_API_TOKEN }}`
-- **Body** : `{ "id": "{{ collectionId }}" }`
-- **ContinueOnFail** : `true`
-
-**Résultat attendu** : Status 200 = succès
-
-### 4. RocketChat Channel
-
-**Node** : "Close RocketChat Channel"
-- **Méthode** : POST
-- **URL** : `{{ ROCKETCHAT_API_URL }}/api/v1/channels.close`
-- **Headers** :
- - `X-Auth-Token: {{ ROCKETCHAT_AUTH_TOKEN }}`
- - `X-User-Id: {{ ROCKETCHAT_USER_ID }}`
-- **Body** : `{ "roomId": "{{ rocketChatRoomId }}" }`
-- **ContinueOnFail** : `true`
-
-**Note** : Le canal est **fermé**, pas supprimé
-
----
-
-## 📤 Réponse N8N
-
-### Format de Réponse (Combine Results)
-
-```javascript
-{
- status: "deleted",
- timestamp: "2024-01-01T12:00:00.000Z",
- details: {
- gitea: true || "already_deleted",
- leantime: true || false,
- outline: true || false,
- rocketchat: true || false
- }
-}
-```
-
-### Envoi à l'API (Save Deletion To API)
-
-Le workflow envoie ensuite les résultats à :
-- **URL** : `{{ MISSION_API_URL }}/mission-deleted`
-- **Méthode** : POST
-- **Headers** : `Authorization: Bearer {{ Keycloak Token }}`
-- **Body** :
- ```json
- {
- "status": "archived",
- "results": {
- "gitea": true,
- "leantime": true,
- "outline": true,
- "rocketchat": true
- }
- }
- ```
-
----
-
-## ⚠️ Points d'Attention
-
-### 1. Gestion des Erreurs
-
-- Tous les nodes de suppression ont `continueOnFail: true`
-- Si une suppression échoue, le workflow continue avec les autres
-- Les résultats indiquent quelles suppressions ont réussi/échoué
-
-### 2. Différences de Comportement
-
-- **Gitea** : Suppression complète du repository
-- **Leantime** : Fermeture (status: "closed"), pas suppression
-- **Outline** : Suppression complète de la collection
-- **RocketChat** : Fermeture du canal, pas suppression
-
-### 3. Extraction du Repo Name
-
-- L'extraction doit gérer différents formats d'URL
-- Si l'extraction échoue, `repoName` sera vide
-- Le workflow N8N gérera le cas où `repoName` est vide
-
-### 4. Mapping des Champs
-
-- **documentationCollectionId** : Mappé depuis `outlineCollectionId`
-- **rocketchatChannelId** : Mappé depuis `rocketChatChannelId` (attention au 'c' minuscule)
-- **leantimeProjectId** : Converti en number (0 si null)
-
----
-
-## 🔍 Debugging
-
-### Logs à Surveiller
-
-1. **Extraction repo name** :
- ```
- Extracted repo name from URL: { url: "...", repoName: "..." }
- ```
-
-2. **Données envoyées à N8N** :
- ```
- Sending deletion data to N8N: { ... }
- ```
-
-3. **Résultat N8N** :
- ```
- N8N Deletion Workflow Result: { success: true, results: {...} }
- ```
-
-### Vérifications
-
-1. **Repo name extrait correctement** ?
- - Vérifier les logs d'extraction
- - Format attendu : nom simple sans URL
-
-2. **Mapping des champs correct** ?
- - `documentationCollectionId` = `outlineCollectionId`
- - `rocketchatChannelId` = `rocketChatChannelId`
-
-3. **N8N a reçu les données** ?
- - Vérifier les logs N8N
- - Vérifier le webhook a été appelé
-
----
-
-## 📝 Exemple Complet
-
-### Données en Base
-
-```typescript
-{
- id: "abc-123",
- name: "Mission Example",
- giteaRepositoryUrl: "https://gite.slm-lab.net/alma/mission-example",
- leantimeProjectId: "123",
- outlineCollectionId: "collection-456",
- rocketChatChannelId: "channel-789"
-}
-```
-
-### Données Envoyées à N8N
-
-```typescript
-{
- missionId: "abc-123",
- name: "Mission Example",
- repoName: "mission-example", // Extrait de l'URL
- leantimeProjectId: 123, // Converti en number
- documentationCollectionId: "collection-456", // Mappé
- rocketchatChannelId: "channel-789", // Mappé (lowercase 'c')
- giteaRepositoryUrl: "https://gite.slm-lab.net/alma/mission-example",
- outlineCollectionId: "collection-456",
- rocketChatChannelId: "channel-789",
- config: {
- N8N_API_KEY: "...",
- MISSION_API_URL: "https://hub.slm-lab.net"
- }
-}
-```
-
-### Données Traitées par N8N
-
-```javascript
-{
- missionData: {
- repoName: "mission-example",
- leantimeId: 123,
- collectionId: "collection-456",
- rocketChatRoomId: "channel-789"
- },
- config: { ... }
-}
-```
-
----
-
-**Document généré le** : $(date)
-**Version** : 1.0
-**Workflow N8N** : NeahMissionDelete_Pro
-**Webhook URL** : https://brain.slm-lab.net/webhook-test/mission-delete
-
diff --git a/NAVBAR_TIME_INTEGRATION.md b/NAVBAR_TIME_INTEGRATION.md
deleted file mode 100644
index 3a224ee9..00000000
--- a/NAVBAR_TIME_INTEGRATION.md
+++ /dev/null
@@ -1,129 +0,0 @@
-# Navigation Bar Time Integration
-
-## 🎯 Overview
-
-The navigation bar (`components/main-nav.tsx`) currently displays a static time that doesn't refresh. This document outlines how to integrate it into the unified refresh system.
-
-## 🔍 Current Issue
-
-**File**: `components/main-nav.tsx` (lines 228-231)
-
-```typescript
-// Current code - STATIC (doesn't refresh)
-const now = new Date();
-const formattedDate = format(now, "d MMMM yyyy", { locale: fr });
-const formattedTime = format(now, "HH:mm");
-```
-
-**Problem**: Time is calculated once when component renders and never updates.
-
-## ✅ Solution
-
-### Step 1: Create Time Component
-
-**File**: `components/main-nav-time.tsx` (✅ Already created)
-
-This component:
-- Uses `useState` to track current time
-- Uses `useUnifiedRefresh` hook for 1-second updates
-- Properly cleans up on unmount
-- No API calls needed (client-side only)
-
-### Step 2: Update MainNav Component
-
-**File**: `components/main-nav.tsx`
-
-**Changes needed**:
-
-1. **Import the new component**:
-```typescript
-import { MainNavTime } from './main-nav-time';
-```
-
-2. **Remove static time code** (lines 228-231):
-```typescript
-// DELETE THESE LINES:
-// Format current date and time
-const now = new Date();
-const formattedDate = format(now, "d MMMM yyyy", { locale: fr });
-const formattedTime = format(now, "HH:mm");
-```
-
-3. **Replace time display** (lines 294-298):
-```typescript
-// BEFORE:
-{/* Center - Date and Time */}
-
-
{formattedDate}
-
{formattedTime}
-
-
-
Marking {markingProgress.current} of {markingProgress.total}...
-
{
- // Error handling...
- }}
- />
-) : null}
-```
-
-### 3. Enhanced Upload API
-
-Updated `/app/api/missions/upload/route.ts` to:
-- Include additional logging
-- Generate and return proper public URLs
-- Improve error handling
-
-### 4. Enhanced Mission Detail API
-
-Modified `/app/api/missions/[missionId]/route.ts` to include public URLs in the response:
-```typescript
-const missionWithUrls = {
- ...mission,
- logoUrl: mission.logo ? getPublicUrl(mission.logo) : null,
- attachments: mission.attachments.map((attachment) => ({
- ...attachment,
- publicUrl: getPublicUrl(attachment.filePath)
- }))
-};
-```
-
-### 5. Added Testing Tools
-
-1. Browser Console Utilities:
- - `window.testMinioConnection()` - Test Minio connectivity
- - `window.getMinioUrl(path)` - Generate a public URL for debugging
-
-2. Server-side Test Script:
- - Created `scripts/test-minio-upload.js` to test uploads from the command line
- - Tests uploading, downloading, and URL generation
-
-## How to Test
-
-1. **Using the browser console:**
- ```javascript
- // Test connection and list files
- window.testMinioConnection()
-
- // Generate URL for a specific path
- window.getMinioUrl('user-123/missions/456/logo.jpg')
- ```
-
-2. **Using the server-side script:**
- ```bash
- node scripts/test-minio-upload.js
- ```
-
-## Required Environment Variables
-
-Make sure these are properly set in your environment:
-- `MINIO_S3_UPLOAD_BUCKET_URL` - The Minio endpoint URL
-- `MINIO_AWS_REGION` - The AWS region (often 'us-east-1' for Minio)
-- `MINIO_AWS_S3_UPLOAD_BUCKET_NAME` - The bucket name
-- `MINIO_ACCESS_KEY` - Access key for Minio
-- `MINIO_SECRET_KEY` - Secret key for Minio
-
-## Additional Notes
-
-1. The same Minio bucket is used for both Pages and Missions.
-2. Pages functionality is working properly, suggesting the Minio configuration itself is correct.
-3. Make sure that the bucket has proper permissions for public read access.
-4. The URL paths for SDG/ODD icons were corrected to use `/F SDG Icons 2019 WEB/F-WEB-Goal-XX.png`
\ No newline at end of file
diff --git a/README.md b/README.md
deleted file mode 100644
index 550c914d..00000000
--- a/README.md
+++ /dev/null
@@ -1,108 +0,0 @@
-# Neah Email Application
-
-A modern email client built with Next.js, featuring email composition, viewing, and management capabilities.
-
-## Email Processing Workflow
-
-The application handles email processing through a centralized workflow:
-
-1. **Email Fetching**: Emails are fetched through the `/api/courrier` endpoints using user credentials stored in the database.
-
-2. **Email Parsing**: Raw email content is parsed using:
- - Server-side: `parseEmail` function from `lib/server/email-parser.ts` (which uses `simpleParser` from the `mailparser` library)
- - API route: `/api/parse-email` provides a REST interface to the parser
-
-3. **HTML Sanitization**: Email HTML content is sanitized and processed using:
- - `sanitizeHtml` function in `lib/utils/email-utils.ts` (centralized implementation)
- - DOMPurify with specific configuration to handle email content safely
-
-4. **Email Display**: Sanitized content is rendered in the UI with proper styling and security measures
-
-5. **Email Composition**: The `ComposeEmail` component handles email creation, replying, and forwarding
- - Email is sent through the `/api/courrier/send` endpoint
-
-## Key Features
-
-- **Email Fetching and Management**: Connect to IMAP servers and manage email fetching and caching logic
-- **Email Composition**: Rich text editor with reply and forwarding capabilities
-- **Email Display**: Secure rendering of HTML emails
-- **Attachment Handling**: View and download attachments
-
-## Project Structure
-
-The project follows a modular structure:
-
-- `/app` - Next.js App Router structure with routes and API endpoints
-- `/components` - React components organized by domain
-- `/lib` - Core library code:
- - `/server` - Server-only code like email parsing
- - `/services` - Domain-specific services, including email service
- - `/reducers` - State management logic
- - `/utils` - Utility functions including the centralized email formatter
-
-## Technologies
-
-- Next.js 14+ with App Router
-- React Server Components
-- TailwindCSS for styling
-- Mailparser for email parsing
-- ImapFlow for email fetching
-- DOMPurify for HTML sanitization
-- Redis for caching
-
-## State Management
-
-Email state is managed through React context and reducers, with server data fetched through React Server Components or client-side API calls as needed.
-
-# Email Formatting
-
-## Centralized Email Formatter
-
-All email formatting is now handled by a centralized formatter in `lib/utils/email-utils.ts`. This ensures consistent handling of:
-
-- Reply and forward formatting
-- HTML sanitization
-- RTL/LTR text direction
-- MIME encoding and decoding for email composition
-
-Key functions include:
-- `formatForwardedEmail`: Format emails for forwarding
-- `formatReplyEmail`: Format emails for replying
-- `sanitizeHtml`: Safely sanitize HTML email content
-- `formatEmailForReplyOrForward`: Compatibility function for both
-- `decodeComposeContent`: Parse MIME content for email composition
-- `encodeComposeContent`: Create MIME-formatted content for sending emails
-
-This centralized approach prevents formatting inconsistencies and direction problems when dealing with emails in different languages.
-
-## Deprecated Functions
-
-Several functions have been deprecated and removed in favor of centralized implementations:
-
-- Check the `DEPRECATED_FUNCTIONS.md` file for a complete list of deprecated functions and their replacements.
-
-## User Management API
-
-The application provides endpoints for managing users in multiple systems:
-
-- **Create User**:
- - Endpoint: `POST /api/users`
- - Creates users in Keycloak, Leantime, and Dolibarr (if they have "mediation" or "expression" roles)
-
-- **Update User**:
- - Endpoint: `PUT /api/users/[userId]`
- - Updates user details in Keycloak
-
-- **Delete User**:
- - Endpoint: `DELETE /api/users?id=[userId]&email=[userEmail]`
- - Deletes users from Keycloak, Leantime, and Dolibarr systems
- - **Important**: Always include both `id` and `email` parameters for complete deletion across all systems
- - The legacy endpoint `DELETE /api/users/[userId]` forwards to the above endpoint
-
-- **Manage Roles**:
- - Endpoint: `PUT /api/users/[userId]/roles`
- - Updates user roles in Keycloak
-
-- **Reset Password**:
- - Endpoint: `PUT /api/users/[userId]/password`
- - Resets user password in Keycloak
\ No newline at end of file
diff --git a/SEPARATED_AUTHENTICATION_FLOWS_EXPLANATION.md b/SEPARATED_AUTHENTICATION_FLOWS_EXPLANATION.md
deleted file mode 100644
index 5e9111bc..00000000
--- a/SEPARATED_AUTHENTICATION_FLOWS_EXPLANATION.md
+++ /dev/null
@@ -1,366 +0,0 @@
-# Why Dashboard and Applications Have Separated Authentication Flows
-
-## Executive Summary
-
-The dashboard and applications use **two completely separate authentication mechanisms** that operate independently:
-
-1. **Dashboard**: Uses **NextAuth.js** with JWT-based sessions (30 days)
-2. **Applications**: Use **Keycloak SSO** directly via browser cookies
-
-This separation is why logging out from the dashboard doesn't automatically log you out from applications opened directly in the browser.
-
----
-
-## Architecture Overview
-
-### Two Independent Authentication Systems
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│ AUTHENTICATION LAYERS │
-├─────────────────────────────────────────────────────────────┤
-│ │
-│ ┌──────────────────────┐ ┌──────────────────────┐ │
-│ │ DASHBOARD AUTH │ │ APPLICATION AUTH │ │
-│ │ │ │ │ │
-│ │ NextAuth.js │ │ Keycloak SSO │ │
-│ │ (JWT Strategy) │ │ (Cookie-based) │ │
-│ │ │ │ │ │
-│ │ - Session: 30 days │ │ - Session: Variable │ │
-│ │ - Stored in: Cookie │ │ - Stored in: Cookie │ │
-│ │ - Domain: Dashboard │ │ - Domain: Keycloak │ │
-│ │ - Independent │ │ - Independent │ │
-│ └──────────────────────┘ └──────────────────────┘ │
-│ │ │ │
-│ └──────────┬───────────────────┘ │
-│ │ │
-│ ┌───────▼────────┐ │
-│ │ KEYCLOAK │ │
-│ │ (IdP Server) │ │
-│ └────────────────┘ │
-│ │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## Why They're Separated
-
-### 1. Different Authentication Purposes
-
-**Dashboard Authentication (NextAuth.js)**:
-- Purpose: Authenticate the **Next.js dashboard application**
-- Method: OAuth 2.0 flow → Get tokens → Store in JWT
-- Session Management: NextAuth manages its own session lifecycle
-- Storage: Encrypted JWT in HTTP-only cookie on dashboard domain
-- Duration: 30 days (configurable in `app/api/auth/options.ts`)
-
-**Application Authentication (Keycloak SSO)**:
-- Purpose: Authenticate **standalone applications** (not embedded in dashboard)
-- Method: Direct Keycloak authentication via browser cookies
-- Session Management: Keycloak manages SSO session lifecycle
-- Storage: Keycloak session cookies on Keycloak domain
-- Duration: Configured in Keycloak (typically 30 minutes to a few hours)
-
-### 2. Different Session Storage Locations
-
-**Dashboard Session**:
-```
-Cookie Name: next-auth.session-token
-Domain: dashboard.example.com
-Path: /
-HttpOnly: Yes
-Secure: Yes (if HTTPS)
-SameSite: Lax
-Content: Encrypted JWT containing:
- - accessToken (Keycloak OAuth token)
- - refreshToken (Keycloak refresh token)
- - idToken (Keycloak ID token)
- - User info (id, email, roles, etc.)
-```
-
-**Application Session**:
-```
-Cookie Name: KEYCLOAK_SESSION
-Domain: keycloak.example.com (or configured domain)
-Path: /
-HttpOnly: Yes
-Secure: Yes
-SameSite: Lax or None (for cross-site)
-Content: Keycloak session identifier
-```
-
-### 3. Different Authentication Flows
-
-**Dashboard Flow**:
-```
-1. User visits dashboard → /signin
-2. NextAuth redirects to Keycloak OAuth endpoint
-3. Keycloak authenticates user
-4. Keycloak redirects back with authorization code
-5. NextAuth exchanges code for tokens
-6. NextAuth creates JWT session
-7. JWT stored in dashboard cookie
-8. Dashboard uses JWT for authentication
-```
-
-**Application Flow** (when opened directly):
-```
-1. User visits application directly (not via dashboard)
-2. Application checks for Keycloak session cookie
-3. If cookie exists → User is authenticated (SSO)
-4. If cookie doesn't exist → Redirect to Keycloak login
-5. Keycloak authenticates user
-6. Keycloak sets session cookie
-7. Application uses cookie for authentication
-```
-
----
-
-## Why Dashboard Logout Doesn't Log Out Applications
-
-### The Problem
-
-When you log out from the dashboard:
-
-1. **Dashboard logout process**:
- - Clears NextAuth session cookie (`next-auth.session-token`)
- - Calls Keycloak logout endpoint with `id_token_hint`
- - Keycloak clears **client session** for dashboard OAuth client
- - Keycloak may clear SSO session (if it's the last client session)
-
-2. **What happens to applications**:
- - Applications don't know about dashboard logout
- - Applications still have Keycloak SSO session cookie
- - Applications continue to work because they use Keycloak cookies, not NextAuth
-
-### Technical Reasons
-
-#### Reason 1: Different Cookie Domains
-
-**Dashboard Cookie**:
-- Domain: `dashboard.example.com`
-- Cleared when dashboard logs out
-- Applications can't access this cookie (different domain)
-
-**Keycloak SSO Cookie**:
-- Domain: `keycloak.example.com` (or configured domain)
-- Not cleared by dashboard logout (unless SSO session is cleared)
-- Applications can access this cookie (same domain as Keycloak)
-
-#### Reason 2: Independent Session Lifecycles
-
-**NextAuth Session**:
-- Managed by NextAuth.js
-- Lifecycle: Created on login → Valid for 30 days → Cleared on logout
-- Independent of Keycloak SSO session
-
-**Keycloak SSO Session**:
-- Managed by Keycloak server
-- Lifecycle: Created on login → Valid until timeout or explicit logout → Cleared on logout
-- Independent of NextAuth session
-
-#### Reason 3: Different Authentication Mechanisms
-
-**Dashboard**:
-- Uses OAuth 2.0 tokens (access token, refresh token)
-- Tokens stored in NextAuth JWT
-- Authentication: Validate JWT → Extract tokens → Use tokens for API calls
-
-**Applications**:
-- Use Keycloak session cookies directly
-- No OAuth tokens involved
-- Authentication: Check for Keycloak session cookie → If exists, user is authenticated
-
-#### Reason 4: Keycloak SSO Session Persistence
-
-**Keycloak maintains two types of sessions**:
-
-1. **Client Session** (per OAuth client):
- - Specific to each OAuth client (dashboard, app1, app2, etc.)
- - Cleared when that specific client logs out
- - Dashboard logout clears dashboard's client session
-
-2. **SSO Session** (realm-wide):
- - Shared across all clients in the realm
- - Persists even after individual client logouts
- - Only cleared when:
- - All client sessions are logged out
- - Explicit SSO session logout
- - Session timeout
- - Admin API logout
-
-**When dashboard logs out**:
-- Dashboard's client session is cleared ✅
-- SSO session may persist if other applications have active sessions ❌
-- Applications continue to work because SSO session is still valid ❌
-
----
-
-## Current Logout Flow Analysis
-
-### What Happens When You Log Out from Dashboard
-
-```
-Step 1: User clicks logout in dashboard
- ↓
-Step 2: Dashboard calls NextAuth signOut()
- → Clears: next-auth.session-token cookie
- → Clears: Dashboard's NextAuth session
- ↓
-Step 3: Dashboard calls /api/auth/end-sso-session
- → Uses Keycloak Admin API
- → Calls: adminClient.users.logout({ id: userId })
- → Clears: All client sessions for user
- → May clear: SSO session (if it's the last client session)
- ↓
-Step 4: Dashboard redirects to Keycloak logout endpoint
- → URL: ${KEYCLOAK_ISSUER}/protocol/openid-connect/logout
- → Parameters: id_token_hint, post_logout_redirect_uri
- → Clears: Dashboard's client session
- → May clear: SSO session (if it's the last client session)
- ↓
-Step 5: Keycloak redirects back to /signin?logout=true
- → Dashboard shows logout message
-```
-
-### What Happens to Applications
-
-```
-Applications opened directly in browser:
- ↓
-Step 1: Application checks for Keycloak session cookie
- → Cookie: KEYCLOAK_SESSION
- → Domain: keycloak.example.com
- ↓
-Step 2: If SSO session still exists:
- → Application finds valid SSO session cookie ✅
- → Application authenticates user automatically ✅
- → User remains logged in ❌
- ↓
-Step 3: If SSO session was cleared:
- → Application doesn't find session cookie ✅
- → Application redirects to Keycloak login ✅
- → User must log in again ✅
-```
-
-### Why Applications Stay Logged In
-
-**Scenario 1: SSO Session Persists**
-- Dashboard logout clears client sessions
-- But SSO session cookie still exists
-- Applications check SSO session cookie → Still valid → User stays logged in
-
-**Scenario 2: Other Applications Have Active Sessions**
-- If other applications are open in other tabs/windows
-- They have active client sessions
-- Keycloak won't clear SSO session (because other clients are still active)
-- All applications stay logged in
-
-**Scenario 3: Cookie Domain Mismatch**
-- Dashboard tries to clear Keycloak cookies client-side
-- But cookies are on different domain (keycloak.example.com)
-- Browser security prevents clearing cross-domain cookies
-- Applications keep their cookies → Stay logged in
-
----
-
-## Why This Architecture Exists
-
-### Historical/Design Reasons
-
-1. **Legacy Applications**:
- - Applications may have existed before the dashboard
- - They were designed to use Keycloak directly
- - Dashboard was added later as a wrapper/portal
-
-2. **Separation of Concerns**:
- - Dashboard: Portal/aggregator (doesn't need to know about app internals)
- - Applications: Standalone services (don't depend on dashboard)
-
-3. **Flexibility**:
- - Applications can be accessed directly (not just via dashboard)
- - Applications can be used independently
- - Dashboard is optional, not required
-
-4. **SSO Design**:
- - Keycloak SSO is designed to work across multiple applications
- - Logging out from one app shouldn't log out from all apps
- - This is by design for SSO functionality
-
-### Technical Constraints
-
-1. **Cookie Security**:
- - Browsers prevent cross-domain cookie access
- - Dashboard can't directly clear Keycloak cookies (different domain)
- - Must use Keycloak logout endpoint or Admin API
-
-2. **Stateless vs Stateful**:
- - NextAuth: Stateless (JWT, no server-side session)
- - Keycloak: Stateful (server-side session, cookies)
-
-3. **OAuth vs Direct Authentication**:
- - Dashboard: Uses OAuth 2.0 (tokens)
- - Applications: Use direct Keycloak authentication (cookies)
-
----
-
-## What Would Be Needed for Unified Logout
-
-To make dashboard logout also log out applications, you would need:
-
-### Option 1: Keycloak Front-Channel Logout (Recommended)
-- Configure all applications to participate in Front-Channel Logout
-- When dashboard logs out, Keycloak notifies all registered applications
-- Applications receive logout notification and clear their sessions
-- **Requires**: Keycloak configuration + Application support
-
-### Option 2: Keycloak Single Logout (SLO)
-- Configure all applications to participate in SLO
-- When one application logs out, all applications are logged out
-- **Requires**: Keycloak configuration + Application support
-
-### Option 3: Clear SSO Session Explicitly
-- Use Keycloak Admin API to end SSO session
-- This clears the realm-wide SSO session
-- All applications lose their authentication
-- **Current Implementation**: Partially implemented (`/api/auth/end-sso-session`)
-- **Issue**: May not clear SSO session cookie if other clients are active
-
-### Option 4: Application Logout Endpoints
-- Each application exposes a logout endpoint
-- Dashboard calls all application logout endpoints
-- Applications clear their own sessions
-- **Requires**: Application modifications + Dashboard coordination
-
----
-
-## Summary
-
-### Why They're Separated
-
-1. **Different purposes**: Dashboard is a portal, applications are standalone services
-2. **Different storage**: Dashboard uses NextAuth JWT, applications use Keycloak cookies
-3. **Different domains**: Cookies are on different domains (security prevents cross-domain access)
-4. **Different lifecycles**: NextAuth session (30 days) vs Keycloak SSO session (variable)
-5. **SSO design**: Keycloak SSO is designed to persist across client logouts
-
-### Why Dashboard Logout Doesn't Log Out Applications
-
-1. **SSO session persists**: Keycloak SSO session may not be cleared
-2. **Other active sessions**: If other applications are open, SSO session stays active
-3. **Cookie domain**: Dashboard can't directly clear Keycloak cookies (different domain)
-4. **Independent mechanisms**: Applications don't know about NextAuth session state
-
-### The Solution
-
-To achieve unified logout, you need to:
-- Configure Keycloak Front-Channel Logout or SLO
-- Ensure all applications participate in logout notifications
-- Or use Admin API to explicitly end SSO session (current implementation attempts this)
-
-The current implementation (`/api/auth/end-sso-session`) tries to clear the SSO session, but it may not work if:
-- Other applications have active sessions
-- SSO session cookie is on a different domain
-- Keycloak configuration prevents SSO session clearing
-
diff --git a/SESSION_CALLBACK_LOGGING_IMPACT_ANALYSIS.md b/SESSION_CALLBACK_LOGGING_IMPACT_ANALYSIS.md
deleted file mode 100644
index a6a76ba9..00000000
--- a/SESSION_CALLBACK_LOGGING_IMPACT_ANALYSIS.md
+++ /dev/null
@@ -1,335 +0,0 @@
-# Session Callback Logging - Impact Analysis
-
-**Date**: 2026-01-01
-**Purpose**: Analyze the impact of reducing session callback logging on the multi-stack architecture
-
----
-
-## 🏗️ Architecture Overview
-
-### Stack Components
-1. **Next.js Dashboard** (this application)
-2. **Keycloak** (SSO/Authentication provider)
-3. **MinIO** (Object storage for files)
-4. **External Services** (Leantime, Rocket.Chat, News API, etc.)
-
-### Integration Points
-- **Keycloak**: OAuth2/OIDC provider, session tokens, role extraction
-- **MinIO**: File storage (mission logos, attachments), S3-compatible API
-- **External APIs**: All require authenticated session
-
----
-
-## 📋 Current Session Callback Logging
-
-### What's Being Logged
-```typescript
-// Lines 407-472 in app/api/auth/options.ts
-- === SESSION CALLBACK START ===
-- Token error status
-- Access token presence
-- Refresh token presence
-- Token roles
-- Token sub (user ID)
-- Token email
-- Token name
-- Token username
-- User roles for session
-- Creating session user object
-- Setting session tokens
-- ✅ Session created successfully
-- Session user details
-- === SESSION CALLBACK END ===
-```
-
-### Why It Was Added
-**Historical Context** (from `DEBUG_502_CALLBACK.md`):
-- Added specifically to debug **502 errors** with Keycloak callbacks
-- Critical for diagnosing authentication failures
-- Helps identify when session callback doesn't execute
-- Essential for troubleshooting SSO flow issues
-
----
-
-## 🔍 Impact Analysis
-
-### 1. Keycloak Integration Impact
-
-**Dependencies**:
-- ✅ **No functional impact**: Logging doesn't affect Keycloak authentication
-- ⚠️ **Debugging impact**: Removing logs makes troubleshooting harder
-- ✅ **Error logging preserved**: Critical errors still logged
-
-**Keycloak Flow**:
-```
-1. User authenticates → Keycloak
-2. Keycloak redirects → Next.js callback
-3. JWT callback extracts tokens
-4. Session callback builds session ← LOGGING HERE
-5. Session used for all API calls
-```
-
-**Recommendation**:
-- Keep error logging (always)
-- Make success logging conditional (DEBUG_SESSION flag)
-
----
-
-### 2. MinIO Integration Impact
-
-**Dependencies**:
-- ✅ **No direct dependency**: MinIO doesn't use session callback logs
-- ✅ **Uses session for auth**: Session object used to verify user permissions
-- ✅ **No impact**: Logging changes won't affect MinIO operations
-
-**MinIO Flow**:
-```
-1. API route calls getServerSession()
-2. Session callback executes (builds session)
-3. Session used to verify user authentication
-4. MinIO operations proceed with authenticated user
-```
-
-**Recommendation**:
-- ✅ **Safe to reduce logging**: No impact on MinIO functionality
-
----
-
-### 3. External Services Impact
-
-**Services**:
-- Leantime (project management)
-- Rocket.Chat (messaging)
-- News API
-- Email/IMAP
-
-**Dependencies**:
-- ✅ **No functional impact**: Services don't read logs
-- ✅ **Session still created**: Logging doesn't affect session creation
-- ✅ **Authentication works**: Session object still valid
-
-**Recommendation**:
-- ✅ **Safe to reduce logging**: No impact on external services
-
----
-
-### 4. Monitoring & Debugging Impact
-
-**Current Usage**:
-- Debugging 502 errors (Keycloak callbacks)
-- Troubleshooting authentication issues
-- Monitoring session creation frequency
-- Identifying session callback failures
-
-**Impact of Reducing Logging**:
-- ⚠️ **Harder to debug**: Less visibility into session creation
-- ✅ **Still debuggable**: Error logging preserved
-- ✅ **Can enable on-demand**: DEBUG_SESSION flag for troubleshooting
-
-**Recommendation**:
-- Use conditional logging with DEBUG_SESSION flag
-- Keep error logging always enabled
-- Document how to enable debug logging
-
----
-
-## ✅ Safe Implementation Strategy
-
-### Phase 1: Conditional Logging (Recommended)
-
-**Approach**: Make success logging conditional, keep error logging always
-
-```typescript
-async session({ session, token }) {
- try {
- // Always log errors
- if (token.error) {
- console.error("❌ Session callback error:", token.error);
- }
-
- // Conditional verbose logging
- const DEBUG_SESSION = process.env.DEBUG_SESSION === 'true' ||
- process.env.NODE_ENV === 'development';
-
- if (DEBUG_SESSION) {
- console.log('=== SESSION CALLBACK START ===');
- console.log('Token error:', token.error);
- console.log('Has accessToken:', !!token.accessToken);
- // ... rest of verbose logging
- }
-
- // Always log critical errors
- if (token.error === "SessionNotActive" ||
- token.error === "NoRefreshToken" ||
- !token.accessToken ||
- !token.refreshToken) {
- console.log("❌ Session invalidated or tokens missing", {
- error: token.error,
- hasAccessToken: !!token.accessToken,
- hasRefreshToken: !!token.refreshToken
- });
- return null as any;
- }
-
- // ... rest of callback logic
-
- if (DEBUG_SESSION) {
- console.log('✅ Session created successfully');
- console.log('Session user id:', session.user.id);
- console.log('=== SESSION CALLBACK END ===');
- }
-
- return session;
- } catch (error) {
- // Always log critical errors
- console.error('❌❌❌ CRITICAL ERROR IN SESSION CALLBACK ❌❌❌');
- console.error('Error:', error);
- throw error;
- }
-}
-```
-
-**Benefits**:
-- ✅ Production: Minimal logging (errors only)
-- ✅ Development: Full logging for debugging
-- ✅ On-demand: Enable with DEBUG_SESSION=true
-- ✅ No functional impact
-
----
-
-### Phase 2: Environment-Based Logging
-
-**Alternative**: Use NODE_ENV
-
-```typescript
-const isDevelopment = process.env.NODE_ENV === 'development';
-
-if (isDevelopment || token.error) {
- // Verbose logging
-}
-```
-
-**Benefits**:
-- ✅ Simple implementation
-- ✅ Automatic in development
-- ⚠️ Less flexible than DEBUG_SESSION flag
-
----
-
-## 🎯 Recommended Approach
-
-### Option 1: DEBUG_SESSION Flag (Best)
-
-**Implementation**:
-- Add `DEBUG_SESSION` environment variable
-- Default: `false` (minimal logging)
-- Set to `true` when debugging needed
-
-**Usage**:
-```bash
-# Production (minimal logging)
-DEBUG_SESSION=false npm start
-
-# Debugging (verbose logging)
-DEBUG_SESSION=true npm start
-```
-
-**Pros**:
-- ✅ Flexible (can enable on-demand)
-- ✅ Production-friendly (minimal logs)
-- ✅ Debug-friendly (full logs when needed)
-- ✅ No code changes needed to toggle
-
-**Cons**:
-- ⚠️ Requires environment variable management
-
----
-
-### Option 2: NODE_ENV Based (Simpler)
-
-**Implementation**:
-- Use `NODE_ENV === 'development'` for verbose logging
-- Always log errors
-
-**Pros**:
-- ✅ Simple (no new env vars)
-- ✅ Automatic (works with existing setup)
-
-**Cons**:
-- ⚠️ Less flexible (can't enable in production easily)
-
----
-
-## 📊 Risk Assessment
-
-| Risk | Impact | Mitigation |
-|------|--------|------------|
-| **Lost debugging capability** | Medium | Keep error logging, add DEBUG_SESSION flag |
-| **Harder to troubleshoot 502 errors** | Medium | Document how to enable debug logging |
-| **Performance impact** | Low | Logging overhead is minimal |
-| **Functional impact** | None | Logging doesn't affect functionality |
-
----
-
-## ✅ Final Recommendation
-
-### Implementation Plan
-
-1. **Keep Error Logging Always** ✅
- - Critical errors always logged
- - Session invalidation always logged
- - Exception handling always logged
-
-2. **Make Success Logging Conditional** ✅
- - Use `DEBUG_SESSION` environment variable
- - Default: `false` (production-friendly)
- - Can enable: `DEBUG_SESSION=true` (debugging)
-
-3. **Document Debugging Process** ✅
- - Add to README or troubleshooting guide
- - Explain when to enable DEBUG_SESSION
- - Document what logs to look for
-
-4. **Test in Staging** ✅
- - Verify error logging still works
- - Test with DEBUG_SESSION=true
- - Test with DEBUG_SESSION=false
-
----
-
-## 🔧 Implementation Checklist
-
-- [ ] Update `app/api/auth/options.ts` with conditional logging
-- [ ] Add `DEBUG_SESSION` to environment variable documentation
-- [ ] Test error logging (should always work)
-- [ ] Test success logging with DEBUG_SESSION=true
-- [ ] Test success logging with DEBUG_SESSION=false
-- [ ] Verify Keycloak authentication still works
-- [ ] Verify MinIO operations still work
-- [ ] Verify external services still work
-- [ ] Update troubleshooting documentation
-
----
-
-## 📝 Summary
-
-**Impact Level**: 🟢 **LOW RISK**
-
-**Key Findings**:
-1. ✅ No functional impact on Keycloak, MinIO, or external services
-2. ✅ Logging was added for debugging, not functionality
-3. ✅ Error logging preserved (critical for troubleshooting)
-4. ✅ Conditional logging provides flexibility
-
-**Recommendation**:
-- ✅ **Proceed with conditional logging**
-- ✅ **Use DEBUG_SESSION flag for flexibility**
-- ✅ **Keep error logging always enabled**
-
-**Confidence**: 🟢 **HIGH** - Safe to implement
-
----
-
-**Generated**: 2026-01-01
-**Next Step**: Implement conditional logging in `app/api/auth/options.ts`
-
diff --git a/SESSION_DURATION_SECURITY_ANALYSIS.md b/SESSION_DURATION_SECURITY_ANALYSIS.md
deleted file mode 100644
index f6636bbe..00000000
--- a/SESSION_DURATION_SECURITY_ANALYSIS.md
+++ /dev/null
@@ -1,233 +0,0 @@
-# NextAuth Session Duration: 30 Days vs 4 Hours - Security Analysis
-
-## Current Configuration
-
-**Current Setting** (`app/api/auth/options.ts:190`):
-```typescript
-session: {
- strategy: "jwt",
- maxAge: 30 * 24 * 60 * 60, // 30 days (2,592,000 seconds)
-}
-```
-
-**Proposed Setting**:
-```typescript
-session: {
- strategy: "jwt",
- maxAge: 4 * 60 * 60, // 4 hours (14,400 seconds)
-}
-```
-
----
-
-## Security Analysis
-
-### ✅ **Why 4 Hours is Better for Security**
-
-1. **Reduced Attack Window**:
- - **30 days**: If session is compromised, attacker has 30 days of access
- - **4 hours**: If session is compromised, attacker has maximum 4 hours of access
- - **Risk Reduction**: 99.4% reduction in maximum exposure time
-
-2. **Industry Best Practices**:
- - **NIST Guidelines**: Recommend session timeouts of 2-8 hours for high-security applications
- - **OWASP**: Recommends session timeouts based on risk level (typically 2-8 hours)
- - **Common Practice**: Most enterprise applications use 4-8 hour sessions
-
-3. **Device Security**:
- - **30 days**: Device left unattended = 30 days of potential unauthorized access
- - **4 hours**: Device left unattended = maximum 4 hours of potential access
- - **Better for**: Shared devices, public computers, unattended workstations
-
-4. **Compliance**:
- - Many security standards (ISO 27001, SOC 2) require reasonable session timeouts
- - 30 days is often considered too long for compliance
- - 4 hours aligns better with security compliance requirements
-
-5. **Stolen Session Cookie**:
- - If session cookie is stolen (XSS, MITM), shorter duration limits damage
- - 4 hours gives attacker limited time to exploit
- - 30 days gives attacker extensive time to exploit
-
-### ⚠️ **Considerations & Trade-offs**
-
-1. **User Experience Impact**:
- - **30 days**: Users rarely need to re-authenticate (convenient)
- - **4 hours**: Users need to re-authenticate every 4 hours (less convenient)
- - **Impact**: Moderate - users will need to log in more frequently
-
-2. **Token Refresh Behavior**:
- - **Good News**: Your code already handles token refresh automatically
- - **How it works**:
- - When NextAuth session expires (4 hours), JWT callback runs
- - If `accessToken` is expired, it calls `refreshAccessToken()`
- - Uses `refreshToken` to get new tokens from Keycloak
- - Session is automatically renewed (if refresh token is still valid)
- - **Result**: Users may not notice the 4-hour expiration if they're active
-
-3. **Keycloak Refresh Token Lifetime**:
- - **Important**: Keycloak refresh tokens typically last 7-30 days
- - **What this means**:
- - NextAuth session expires after 4 hours
- - But refresh token is still valid (e.g., 7 days)
- - NextAuth automatically refreshes tokens
- - User stays logged in seamlessly (if active)
- - **Only expires if**: User is inactive for longer than refresh token lifetime
-
-4. **Keycloak Session Alignment**:
- - **Current Issue**: Keycloak sessions typically expire in 30 minutes to a few hours
- - **With 4-hour NextAuth session**:
- - Better alignment with Keycloak session timeouts
- - Reduces session mismatch issues
- - Iframe applications will have more consistent session state
-
----
-
-## How It Will Work
-
-### Session Lifecycle with 4-Hour maxAge
-
-```
-User logs in
- ↓
-NextAuth creates JWT session (expires in 4 hours)
- ↓
-User is active for 2 hours
- ↓
-User makes request → NextAuth checks session
- ↓
-Session still valid (< 4 hours) → Continue
- ↓
-User is active for 3 hours
- ↓
-User makes request → NextAuth checks session
- ↓
-Session still valid (< 4 hours) → Continue
- ↓
-User is active for 4.5 hours (session expired)
- ↓
-User makes request → NextAuth checks session
- ↓
-Session expired → JWT callback runs
- ↓
-Checks accessToken expiration
- ↓
-If accessToken expired → Calls refreshAccessToken()
- ↓
-Uses refreshToken to get new tokens from Keycloak
- ↓
-If refreshToken still valid → New session created (another 4 hours)
- ↓
-User continues seamlessly (no re-authentication needed)
- ↓
-If refreshToken expired → User must re-authenticate
-```
-
-### When User Must Re-authenticate
-
-**User must re-authenticate if**:
-1. **Inactive for longer than refresh token lifetime** (typically 7-30 days)
-2. **Refresh token is revoked** (logout, admin action, security event)
-3. **Keycloak session is invalidated** (logout from another application)
-
-**User does NOT need to re-authenticate if**:
-1. **Active within refresh token lifetime** (automatic token refresh)
-2. **Session expires but refresh token is valid** (automatic renewal)
-
----
-
-## Recommendations
-
-### ✅ **Recommendation: Implement 4-Hour Session**
-
-**Reasons**:
-1. ✅ **Significantly better security** (99.4% reduction in exposure window)
-2. ✅ **Aligns with industry best practices** (NIST, OWASP)
-3. ✅ **Better compliance** (meets security standards)
-4. ✅ **Better alignment with Keycloak sessions**
-5. ✅ **Minimal UX impact** (automatic token refresh handles renewal)
-6. ✅ **Code already supports it** (token refresh mechanism exists)
-
-### ⚠️ **Important Considerations**
-
-1. **Verify Keycloak Refresh Token Lifetime**:
- - Check Keycloak configuration for refresh token lifetime
- - Ensure it's longer than 4 hours (typically 7-30 days)
- - If shorter, users will need to re-authenticate frequently
-
-2. **Monitor User Experience**:
- - Track how often users need to re-authenticate
- - If too frequent, consider increasing to 6-8 hours
- - Balance security with usability
-
-3. **Consider Activity-Based Extension**:
- - Current implementation: Fixed 4-hour expiration
- - Alternative: Extend session on activity (sliding window)
- - Requires additional implementation (activity tracking)
-
-4. **Keycloak Session Configuration**:
- - Consider aligning Keycloak SSO session timeout with NextAuth
- - Or ensure Keycloak session is longer than NextAuth session
- - Prevents session mismatch issues
-
-### 📋 **Implementation Checklist**
-
-Before implementing:
-
-- [ ] Verify Keycloak refresh token lifetime (should be > 4 hours)
-- [ ] Test token refresh flow with 4-hour session
-- [ ] Monitor user re-authentication frequency
-- [ ] Consider user feedback on session duration
-- [ ] Document the change for users (if needed)
-- [ ] Update security documentation
-
----
-
-## Comparison Table
-
-| Aspect | 30 Days | 4 Hours | Winner |
-|--------|---------|---------|--------|
-| **Security** | Low (long exposure window) | High (short exposure window) | ✅ 4 Hours |
-| **User Convenience** | High (rare re-authentication) | Medium (automatic refresh) | ✅ 30 Days |
-| **Compliance** | Poor (too long) | Good (meets standards) | ✅ 4 Hours |
-| **Risk Reduction** | Low | High (99.4% reduction) | ✅ 4 Hours |
-| **Keycloak Alignment** | Poor (mismatch) | Good (better alignment) | ✅ 4 Hours |
-| **Token Refresh** | Works | Works (same mechanism) | ✅ Tie |
-
----
-
-## Conclusion
-
-**Recommendation: Change to 4 hours**
-
-**Why**:
-- Significantly better security posture
-- Aligns with industry best practices
-- Better compliance with security standards
-- Minimal UX impact (automatic token refresh)
-- Better alignment with Keycloak session timeouts
-- Code already supports it
-
-**Implementation**:
-- Simple change: `maxAge: 4 * 60 * 60`
-- No code changes needed (token refresh already works)
-- Monitor user experience and adjust if needed
-
-**Alternative Consideration**:
-- If 4 hours is too aggressive, consider 6-8 hours as a middle ground
-- Still provides significant security improvement over 30 days
-- Better user experience than 4 hours
-
----
-
-## Final Verdict
-
-**✅ Yes, change to 4 hours** - This is a good security practice that:
-- Significantly reduces security risk
-- Aligns with industry standards
-- Has minimal UX impact (automatic refresh)
-- Works with existing code
-- Better aligns with Keycloak sessions
-
-The only trade-off is slightly more frequent re-authentication for inactive users, but this is a reasonable security trade-off.
-
diff --git a/SSO_FLOW_ANALYSIS.md b/SSO_FLOW_ANALYSIS.md
deleted file mode 100644
index 4d296177..00000000
--- a/SSO_FLOW_ANALYSIS.md
+++ /dev/null
@@ -1,250 +0,0 @@
-# SSO Flow Analysis - Keycloak External Logout Issue
-
-## Current Flow Trace
-
-### Scenario: User logs out from Keycloak directly, then accesses dashboard
-
-**Step-by-step flow:**
-
-1. **Initial State (Before Keycloak Logout)**
- - User is logged into Dashboard via NextAuth
- - NextAuth JWT contains:
- - `accessToken`: Valid Keycloak OAuth token
- - `refreshToken`: Valid Keycloak refresh token
- - `idToken`: Valid Keycloak ID token
- - Keycloak session cookies are set in browser
- - Iframe applications can authenticate via Keycloak cookies
-
-2. **User Logs Out from Keycloak Directly (External Application)**
- - External application calls: `POST /realms/{realm}/protocol/openid-connect/logout`
- - Keycloak invalidates:
- - ✅ Keycloak session cookies (cleared)
- - ✅ Keycloak refresh token (invalidated)
- - ✅ Keycloak access token (invalidated)
- - ❌ **NextAuth JWT still contains old tokens** (NextAuth doesn't know about logout)
- - ❌ **NextAuth session cookie still valid** (30-day expiration)
-
-3. **User Accesses Dashboard**
- - Browser sends NextAuth session cookie
- - NextAuth decrypts JWT
- - JWT contains old (now invalid) tokens
- - **Token expiration check**: `Date.now() < (token.accessTokenExpires as number) * 1000`
- - If token hasn't expired yet (by timestamp), NextAuth returns existing token
- - **Problem**: Token is invalid in Keycloak, but NextAuth doesn't know yet
-
-4. **User Navigates to Iframe Application**
- - `ResponsiveIframe` component mounts
- - `useEffect` triggers: `refreshSession()`
- - Calls: `GET /api/auth/refresh-keycloak-session`
-
-5. **Refresh Endpoint Execution**
- ```
- GET /api/auth/refresh-keycloak-session
- → getServerSession(authOptions)
- → Reads NextAuth JWT from cookie
- → JWT contains old refreshToken (invalid)
- → Calls Keycloak: POST /token with old refreshToken
- → Keycloak responds: { error: 'invalid_grant', error_description: 'Token is not active' }
- → Returns 401 with SessionInvalidated error
- ```
-
-6. **ResponsiveIframe Handles Error**
- - Detects `SessionInvalidated` error
- - Redirects to `/signin`
- - User signs in again
- - Gets NEW tokens from Keycloak
-
-7. **User Returns to Iframe (After Re-login)**
- - **Problem**: If NextAuth JWT callback hasn't run yet, it might still have old tokens
- - OR: The new session is created, but iframe component might be using cached session
- - OR: The refresh endpoint is called again before new session is fully established
-
-## Root Cause Analysis
-
-### Issue 1: Stale Token Detection
-
-**Problem**: NextAuth only tries to refresh tokens when they're expired (by timestamp). If a token is invalidated externally (Keycloak logout), NextAuth won't know until it tries to refresh.
-
-**Current Flow**:
-```
-JWT Callback:
- if (Date.now() < token.accessTokenExpires * 1000) {
- return token; // Returns stale token without checking Keycloak
- }
- // Only refreshes if expired by timestamp
-```
-
-**What Should Happen**:
-- When accessing iframe, we proactively refresh to validate token
-- But if refresh fails, we need to clear the NextAuth session immediately
-
-### Issue 2: Session Invalidation Timing
-
-**Problem**: When refresh fails:
-1. Refresh endpoint returns `SessionInvalidated`
-2. ResponsiveIframe redirects to `/signin`
-3. User signs in, gets new tokens
-4. **But**: NextAuth JWT might still have old tokens cached until next JWT callback execution
-
-**Current Behavior**:
-- Redirect to signin happens
-- User re-authenticates
-- New session is created
-- But old session might still be in browser cache/cookies
-
-### Issue 3: Infinite Redirect Loop Potential
-
-**Problem**: If the refresh endpoint keeps failing:
-- ResponsiveIframe redirects to `/signin`
-- User signs in
-- Returns to iframe
-- Refresh endpoint called again
-- If new session isn't fully established, it might still use old tokens
-- Loop continues
-
-## Current Code Flow
-
-### ResponsiveIframe Component Flow
-
-```typescript
-1. Component mounts with session
-2. useEffect triggers refreshSession()
-3. Calls GET /api/auth/refresh-keycloak-session
-4. If 401 + SessionInvalidated:
- → window.location.href = '/signin'
- → User redirected
-5. User signs in again
-6. Returns to iframe page
-7. Component mounts again
-8. useEffect triggers refreshSession() again
-9. If session still has old tokens → fails again
-```
-
-### Refresh Endpoint Flow
-
-```typescript
-GET /api/auth/refresh-keycloak-session
-1. getServerSession(authOptions)
- → Reads JWT from cookie
- → JWT callback runs
- → If token expired: refreshAccessToken()
- → If token not expired: returns existing token (might be invalid!)
-2. Uses session.refreshToken
-3. Calls Keycloak refresh endpoint
-4. If invalid_grant: Returns SessionInvalidated
-```
-
-### JWT Callback Flow
-
-```typescript
-async jwt({ token, account, profile }) {
- // Initial login: account & profile present
- if (account && profile) {
- // Store tokens
- }
-
- // Subsequent requests
- else if (token.accessToken) {
- // Check expiration
- if (Date.now() < token.accessTokenExpires * 1000) {
- return token; // ⚠️ Returns token without validating with Keycloak
- }
-
- // Only refreshes if expired by timestamp
- return refreshAccessToken(token);
- }
-}
-```
-
-## The Problem
-
-**Key Issue**: NextAuth JWT callback only checks token expiration by timestamp. It doesn't validate that the token is still valid in Keycloak. So:
-
-1. User logs out from Keycloak → Token invalidated
-2. NextAuth JWT still has token (not expired by timestamp)
-3. JWT callback returns existing token (assumes it's valid)
-4. Refresh endpoint tries to use invalid refresh token
-5. Fails, redirects to signin
-6. User signs in, but if JWT callback hasn't run with new account, might still have old token
-
-## Why It Gets Stuck
-
-Looking at the logs:
-```
-Failed to refresh Keycloak session: { error: 'invalid_grant', error_description: 'Token is not active' }
-GET /api/auth/refresh-keycloak-session 401
-→ Redirects to /signin
-→ User signs in
-→ Returns to iframe
-→ refresh-keycloak-session called again
-→ Still fails (401)
-```
-
-**Possible reasons**:
-1. **Session not fully updated**: After signin, NextAuth creates new session, but refresh endpoint might be reading old session from cookie before it's updated
-2. **Token not refreshed in JWT**: The new tokens from signin might not be stored in JWT yet when refresh endpoint is called
-3. **Cookie caching**: Browser might be sending old session cookie
-4. **Race condition**: Refresh endpoint called before new session is established
-
-## Recommendations (Without Code Changes)
-
-### 1. Check Session State After Signin
-
-After user signs in and is redirected back:
-- Verify that `getServerSession()` returns new session with valid tokens
-- Check that JWT callback has run and stored new tokens
-- Ensure session cookie is updated in browser
-
-### 2. Add Delay/Retry Logic
-
-In ResponsiveIframe:
-- After redirect from signin, wait a moment before calling refresh endpoint
-- Or check if session has been updated before calling refresh
-- Add retry logic with exponential backoff
-
-### 3. Validate Token Before Using
-
-In refresh endpoint:
-- Before using refreshToken, validate that accessToken is still valid
-- Or check token age - if token is old, force refresh even if not expired
-
-### 4. Clear Session on Invalid Token
-
-When refresh fails with invalid_grant:
-- Don't just redirect - also clear NextAuth session cookie
-- Force complete re-authentication
-- Ensure old session is completely removed
-
-### 5. Check Keycloak Session Status
-
-Before calling refresh endpoint:
-- Check if Keycloak session is still active
-- Use Keycloak's userinfo endpoint to validate access token
-- Only refresh if token is actually invalid
-
-## Current Behavior Summary
-
-**What's Happening**:
-1. ✅ User logs out from Keycloak → Keycloak invalidates tokens
-2. ✅ User accesses dashboard → NextAuth still has old tokens (not expired by timestamp)
-3. ✅ User goes to iframe → Refresh endpoint called
-4. ✅ Refresh fails → Detects invalid token
-5. ✅ Redirects to signin → User re-authenticates
-6. ⚠️ **Issue 1**: Storage initialization fails during signin (`createUserFolderStructure` not exported)
-7. ⚠️ **Issue 2**: After re-authentication, refresh endpoint might still be using old session
-8. ⚠️ **Result**: Gets stuck in redirect loop or keeps failing
-
-**Root Cause**: NextAuth doesn't proactively validate tokens with Keycloak. It only checks expiration timestamps. When tokens are invalidated externally, NextAuth doesn't know until it tries to use them.
-
-**Additional Issue Confirmed**:
-- Storage initialization fails during signin process
-- Error: `createUserFolderStructure is not a function`
-- This prevents complete signin initialization
-- May contribute to session not being fully established
-
----
-
-**Analysis Date**: 2024
-**Status**: Issue Identified
-**Next Steps**: Implement proactive token validation or improve session invalidation handling
-
diff --git a/SSO_FLOW_CONFIRMED.md b/SSO_FLOW_CONFIRMED.md
deleted file mode 100644
index 207e902a..00000000
--- a/SSO_FLOW_CONFIRMED.md
+++ /dev/null
@@ -1,207 +0,0 @@
-# SSO Flow Analysis - Confirmed Issues
-
-## Browser Console Evidence
-
-Based on the browser console error provided, here's what's happening:
-
-### Confirmed Flow
-
-1. **User logs out from Keycloak directly** (external application)
- - Keycloak invalidates all tokens and session
-
-2. **User accesses Dashboard**
- - NextAuth session still exists (30-day expiration)
- - JWT contains old, now-invalid tokens
- - Token expiration check: `Date.now() < token.accessTokenExpires * 1000`
- - If token hasn't expired by timestamp → JWT callback returns old token
- - **Problem**: Token is invalid in Keycloak, but NextAuth doesn't validate it
-
-3. **User navigates to iframe application**
- - `ResponsiveIframe` component mounts
- - Calls `GET /api/auth/refresh-keycloak-session`
- - Refresh endpoint uses old `refreshToken` from session
- - Keycloak responds: `{ error: 'invalid_grant', error_description: 'Token is not active' }`
- - Returns 401 with `SessionInvalidated` error
-
-4. **Redirect to Signin**
- - `ResponsiveIframe` detects `SessionInvalidated`
- - Redirects: `window.location.href = '/signin'`
- - User lands on signin page
-
-5. **Signin Process Starts**
- - `app/signin/page.tsx` detects unauthenticated status
- - Triggers: `signIn("keycloak", { callbackUrl: "/" })`
- - User authenticates with Keycloak
- - Gets NEW tokens from Keycloak
- - NextAuth callback stores new tokens in JWT
-
-6. **Storage Initialization Fails** ⚠️ **CONFIRMED ISSUE**
- - Signin page detects session available
- - Calls: `POST /api/storage/init`
- - Storage endpoint tries to call: `createUserFolderStructure(session.user.id)`
- - **Error**: `createUserFolderStructure is not a function`
- - Storage initialization fails
- - Signin page shows "Échec de l'initialisation"
- - **Impact**: User might not be fully signed in, or session might not be complete
-
-7. **User Returns to Iframe** (After Signin)
- - Navigates to iframe application again
- - `ResponsiveIframe` component mounts
- - Calls refresh endpoint again
- - **If storage init failed**: Session might not be fully established
- - **If new session not ready**: Might still use old tokens
- - Refresh fails again → Redirects to signin → Loop
-
-## Confirmed Issues
-
-### Issue 1: Storage Initialization Failure ✅ CONFIRMED
-
-**Error**: `createUserFolderStructure is not a function`
-
-**Location**: `app/api/storage/init/route.ts:16`
-
-**Impact on SSO Flow**:
-- Storage initialization is part of signin process
-- If it fails, signin might not complete properly
-- Session might not be fully established
-- When user tries to access iframe, refresh endpoint might fail because:
- - Session not complete
- - Or still using old tokens if new session wasn't saved
-
-**Evidence from Browser**:
-```
-Failed to initialize storage: "{\"error\":\"Failed to initialize storage\",\"details\":\"(0 , _lib_s3__WEBPACK_IMPORTED_MODULE_3__.createUserFolderStructure) is not a function\"}"
-```
-
-### Issue 2: Stale Token in NextAuth JWT ✅ CONFIRMED
-
-**Problem**: When Keycloak session is invalidated externally:
-- NextAuth JWT still contains old tokens
-- JWT callback only checks expiration timestamp
-- Doesn't validate with Keycloak that token is still valid
-- Returns stale token until expiration timestamp is reached
-
-**Evidence from Terminal**:
-```
-Failed to refresh Keycloak session: { error: 'invalid_grant', error_description: 'Token is not active' }
-GET /api/auth/refresh-keycloak-session 401
-```
-
-### Issue 3: Race Condition After Re-authentication ✅ CONFIRMED
-
-**Problem**: After user signs in again:
-- New session is created
-- But refresh endpoint might be called before:
- - JWT callback has run with new account
- - New tokens are stored in JWT
- - Session cookie is updated in browser
-- Result: Refresh endpoint still uses old tokens
-
-**Evidence**: Multiple failed refresh attempts after signin
-
-## Complete Flow Diagram (Confirmed)
-
-```
-1. User logs out from Keycloak (external)
- ↓
-2. Keycloak invalidates:
- - Session cookies ✅
- - Refresh token ✅
- - Access token ✅
- ↓
-3. User accesses Dashboard
- - NextAuth JWT has old tokens (not expired by timestamp)
- - JWT callback returns old token (doesn't validate with Keycloak)
- ↓
-4. User navigates to iframe
- - ResponsiveIframe calls refresh endpoint
- - Uses old refreshToken from session
- ↓
-5. Keycloak rejects: "Token is not active"
- ↓
-6. Refresh endpoint returns 401 SessionInvalidated
- ↓
-7. Redirect to /signin
- ↓
-8. User authenticates with Keycloak
- - Gets NEW tokens
- - NextAuth stores new tokens in JWT
- ↓
-9. Storage initialization called
- - ⚠️ FAILS: createUserFolderStructure not found
- - Signin process incomplete
- ↓
-10. User navigates to iframe again
- - Refresh endpoint called
- - ⚠️ Might still use old tokens (if new session not ready)
- - OR: Session incomplete due to storage init failure
- - Fails again → Redirects to signin
- ↓
-11. LOOP or stuck state
-```
-
-## Root Causes (Confirmed)
-
-1. **No Proactive Token Validation**
- - NextAuth only checks expiration timestamps
- - Doesn't validate tokens with Keycloak
- - Stale tokens remain in JWT until timestamp expiration
-
-2. **Storage Initialization Failure**
- - Missing function: `createUserFolderStructure`
- - Prevents complete signin initialization
- - May cause session to be incomplete
-
-3. **Race Condition**
- - Refresh endpoint called before new session fully established
- - Browser might send old session cookie
- - JWT callback might not have run yet with new account
-
-4. **No Session Invalidation on External Logout**
- - When Keycloak session invalidated externally
- - NextAuth doesn't know about it
- - Continues using invalid tokens
-
-## Impact on User Experience
-
-**What User Sees**:
-1. Logs out from Keycloak (external app)
-2. Accesses Dashboard → Still logged in (NextAuth session valid)
-3. Tries to access iframe application
-4. Gets redirected to signin
-5. Signs in again
-6. Storage initialization fails (error message)
-7. Tries to access iframe again
-8. Gets redirected to signin again
-9. **Stuck in loop or keeps getting disconnected**
-
-## Recommendations
-
-### Immediate Fixes Needed
-
-1. **Fix Storage Initialization**
- - Export `createUserFolderStructure` from `lib/s3.ts`
- - Or remove storage init from signin flow if not critical
- - Prevents signin from failing
-
-2. **Proactive Token Validation**
- - Before using tokens, validate with Keycloak
- - Use Keycloak's userinfo endpoint to check token validity
- - Clear session if token invalid
-
-3. **Session Invalidation on Refresh Failure**
- - When refresh fails with invalid_grant
- - Immediately clear NextAuth session cookie
- - Force complete re-authentication
-
-4. **Delay Refresh After Signin**
- - After redirect from signin, wait for session to be established
- - Check session status before calling refresh endpoint
- - Add retry logic with backoff
-
----
-
-**Analysis Date**: 2024
-**Status**: Issues Confirmed
-**Evidence**: Browser console + Terminal logs
-
diff --git a/STACK_QUALITY_AND_FLOW_ANALYSIS.md b/STACK_QUALITY_AND_FLOW_ANALYSIS.md
deleted file mode 100644
index c6409908..00000000
--- a/STACK_QUALITY_AND_FLOW_ANALYSIS.md
+++ /dev/null
@@ -1,540 +0,0 @@
-# Stack Quality & Flow Analysis Report
-
-## Executive Summary
-
-This document provides a comprehensive analysis of the codebase quality, architecture patterns, and identifies critical issues in the notification and widget update flows.
-
-**Overall Assessment**: ⚠️ **Moderate Quality** - Good foundation with several critical issues that need attention.
-
----
-
-## 🔴 Critical Issues
-
-### 1. **Memory Leak: Multiple Polling Intervals**
-
-**Location**: `hooks/use-notifications.ts`, `components/parole.tsx`, `components/calendar/calendar-widget.tsx`
-
-**Problem**:
-- `useNotifications` hook creates polling intervals that may not be properly cleaned up
-- Multiple components using the hook can create duplicate intervals
-- `startPolling()` returns a cleanup function but it's not properly used in the useEffect
-
-**Code Issue**:
-```typescript
-// Line 226 in use-notifications.ts
-return () => stopPolling(); // This return is inside startPolling, not useEffect!
-```
-
-**Impact**: Memory leaks, excessive API calls, degraded performance
-
-**Fix Required**:
-```typescript
-useEffect(() => {
- isMountedRef.current = true;
-
- if (status === 'authenticated' && session?.user) {
- fetchNotificationCount(true);
- fetchNotifications();
- startPolling();
- }
-
- return () => {
- isMountedRef.current = false;
- stopPolling(); // ✅ Correct placement
- };
-}, [status, session?.user, fetchNotificationCount, fetchNotifications, startPolling, stopPolling]);
-```
-
----
-
-### 2. **Race Condition: Notification Badge Double Fetching**
-
-**Location**: `components/notification-badge.tsx`
-
-**Problem**:
-- Multiple `useEffect` hooks trigger `manualFetch()` simultaneously
-- Lines 65-70, 82-87, and 92-99 all trigger fetches
-- No debouncing or request deduplication
-
-**Code Issue**:
-```typescript
-// Line 65-70: Fetch on dropdown open
-useEffect(() => {
- if (isOpen && status === 'authenticated') {
- manualFetch();
- }
-}, [isOpen, status]);
-
-// Line 82-87: Fetch on mount
-useEffect(() => {
- if (status === 'authenticated') {
- manualFetch();
- }
-}, [status]);
-
-// Line 92-99: Fetch on handleOpenChange
-const handleOpenChange = (open: boolean) => {
- setIsOpen(open);
- if (open && status === 'authenticated') {
- manualFetch(); // Duplicate fetch!
- }
-};
-```
-
-**Impact**: Unnecessary API calls, potential race conditions, poor UX
-
-**Fix Required**: Consolidate fetch logic, add request deduplication
-
----
-
-### 3. **Redis KEYS Command Performance Issue**
-
-**Location**: `lib/services/notifications/notification-service.ts` (line 293)
-
-**Problem**:
-- Using `redis.keys()` which is O(N) and blocks Redis
-- Can cause performance degradation in production
-
-**Code Issue**:
-```typescript
-// Line 293 - BAD
-const listKeys = await redis.keys(listKeysPattern);
-if (listKeys.length > 0) {
- await redis.del(...listKeys);
-}
-```
-
-**Impact**: Redis blocking, slow response times, potential timeouts
-
-**Fix Required**: Use `SCAN` instead of `KEYS`:
-```typescript
-// GOOD - Use SCAN
-let cursor = '0';
-do {
- const [nextCursor, keys] = await redis.scan(cursor, 'MATCH', listKeysPattern, 'COUNT', 100);
- cursor = nextCursor;
- if (keys.length > 0) {
- await redis.del(...keys);
- }
-} while (cursor !== '0');
-```
-
----
-
-### 4. **Infinite Loop Risk: useEffect Dependencies**
-
-**Location**: `hooks/use-notifications.ts` (line 255)
-
-**Problem**:
-- `useEffect` includes functions in dependencies that are recreated on every render
-- `fetchNotificationCount`, `fetchNotifications`, `startPolling`, `stopPolling` are in deps
-- These functions depend on `session?.user` which changes, causing re-renders
-
-**Code Issue**:
-```typescript
-useEffect(() => {
- // ...
-}, [status, session?.user, fetchNotificationCount, fetchNotifications, startPolling, stopPolling]);
-// ❌ Functions are recreated, causing infinite loops
-```
-
-**Impact**: Infinite re-renders, excessive API calls, browser freezing
-
-**Fix Required**: Remove function dependencies or use `useCallback` properly
-
----
-
-### 5. **Background Refresh Memory Leak**
-
-**Location**: `lib/services/notifications/notification-service.ts` (line 326)
-
-**Problem**:
-- `setTimeout` in `scheduleBackgroundRefresh` creates closures that may not be cleaned up
-- No way to cancel pending background refreshes
-- Can accumulate in serverless environments
-
-**Code Issue**:
-```typescript
-setTimeout(async () => {
- // This closure holds references and may not be garbage collected
- await this.getNotificationCount(userId);
- await this.getNotifications(userId, 1, 20);
-}, 0);
-```
-
-**Impact**: Memory leaks, especially in serverless/edge environments
-
-**Fix Required**: Use proper cleanup mechanism or job queue
-
----
-
-## ⚠️ High Priority Issues
-
-### 6. **Widget Update Race Conditions**
-
-**Location**: Multiple widget components
-
-**Problem**:
-- Widgets don't coordinate updates
-- Multiple widgets can trigger simultaneous API calls
-- No request deduplication
-
-**Affected Widgets**:
-- `components/calendar.tsx` - Auto-refresh every 5 minutes
-- `components/parole.tsx` - Auto-polling every 30 seconds
-- `components/news.tsx` - Manual refresh only
-- `components/flow.tsx` - Manual refresh only
-- `components/email.tsx` - Manual refresh only
-
-**Impact**: Unnecessary load on backend, potential rate limiting
-
-**Fix Required**: Implement request deduplication layer or use React Query/SWR
-
----
-
-### 7. **Redis Connection Singleton Issues**
-
-**Location**: `lib/redis.ts`
-
-**Problem**:
-- Singleton pattern but no proper connection pooling
-- In serverless environments, connections may not be reused
-- No connection health monitoring
-- Race condition in `getRedisClient()` when `isConnecting` is true
-
-**Code Issue**:
-```typescript
-if (isConnecting) {
- if (redisClient) return redisClient;
- // ⚠️ What if redisClient is null but isConnecting is true?
- console.warn('Redis connection in progress, creating temporary client');
-}
-```
-
-**Impact**: Connection leaks, connection pool exhaustion, degraded performance
-
-**Fix Required**: Implement proper connection pool or use Redis connection manager
-
----
-
-### 8. **Error Handling Gaps**
-
-**Location**: Multiple files
-
-**Problems**:
-- Errors are logged but not always handled gracefully
-- No retry logic for transient failures
-- No circuit breaker pattern
-- Widgets show errors but don't recover automatically
-
-**Examples**:
-- `components/notification-badge.tsx` - Shows error but no auto-retry
-- `lib/services/notifications/notification-service.ts` - Errors return empty arrays silently
-- Widget components - Errors stop updates, no recovery
-
-**Impact**: Poor UX, silent failures, degraded functionality
-
----
-
-### 9. **Cache Invalidation Issues**
-
-**Location**: `lib/services/notifications/notification-service.ts`
-
-**Problem**:
-- Cache invalidation uses `KEYS` command (blocking)
-- No partial cache invalidation
-- Background refresh may not invalidate properly
-- Race condition: cache can be invalidated while being refreshed
-
-**Impact**: Stale data, inconsistent state
-
----
-
-### 10. **Excessive Logging**
-
-**Location**: Throughout codebase
-
-**Problem**:
-- Console.log statements everywhere
-- No log levels
-- Production code has debug logs
-- Performance impact from string concatenation
-
-**Impact**: Performance degradation, log storage costs, security concerns
-
-**Fix Required**: Use proper logging library with levels (e.g., Winston, Pino)
-
----
-
-## 📊 Architecture Quality Assessment
-
-### Strengths ✅
-
-1. **Adapter Pattern**: Well-implemented notification adapter pattern
-2. **Separation of Concerns**: Clear separation between services, hooks, and components
-3. **Type Safety**: Good TypeScript usage
-4. **Caching Strategy**: Redis caching implemented
-5. **Error Boundaries**: Some error handling present
-
-### Weaknesses ❌
-
-1. **No State Management**: Using local state instead of global state management
-2. **No Request Deduplication**: Multiple components can trigger same API calls
-3. **No Request Cancellation**: No way to cancel in-flight requests
-4. **No Optimistic Updates**: UI doesn't update optimistically
-5. **No Offline Support**: No handling for offline scenarios
-6. **No Request Queue**: No queuing mechanism for API calls
-
----
-
-## 🔄 Flow Analysis
-
-### Notification Flow Issues
-
-#### Flow Diagram (Current - Problematic):
-```
-User Action / Polling
- ↓
-useNotifications Hook (multiple instances)
- ↓
-Multiple API Calls (no deduplication)
- ↓
-NotificationService (Redis cache check)
- ↓
-Adapter Calls (parallel, but no error aggregation)
- ↓
-Response (may be stale due to race conditions)
-```
-
-#### Issues:
-1. **Multiple Hook Instances**: `NotificationBadge` and potentially other components use `useNotifications`, creating multiple polling intervals
-2. **No Request Deduplication**: Same request can be made multiple times simultaneously
-3. **Cache Race Conditions**: Background refresh can conflict with user requests
-4. **No Request Cancellation**: Old requests aren't cancelled when new ones start
-
-### Widget Update Flow Issues
-
-#### Flow Diagram (Current - Problematic):
-```
-Component Mount
- ↓
-useEffect triggers fetch
- ↓
-API Call (no coordination with other widgets)
- ↓
-State Update (may cause unnecessary re-renders)
- ↓
-Auto-refresh interval (no cleanup guarantee)
-```
-
-#### Issues:
-1. **No Coordination**: Widgets don't know about each other's updates
-2. **Duplicate Requests**: Same data fetched multiple times
-3. **Cleanup Issues**: Intervals may not be cleaned up properly
-4. **No Stale-While-Revalidate**: No background updates
-
----
-
-## 🎯 Recommendations
-
-### Immediate Actions (Critical)
-
-1. **Fix Memory Leaks**
- - Fix `useNotifications` cleanup
- - Ensure all intervals are cleared
- - Add cleanup in all widget components
-
-2. **Fix Race Conditions**
- - Implement request deduplication
- - Fix notification badge double fetching
- - Add request cancellation
-
-3. **Fix Redis Performance**
- - Replace `KEYS` with `SCAN`
- - Implement proper connection pooling
- - Add connection health checks
-
-### Short-term Improvements (High Priority)
-
-1. **Implement Request Management**
- - Use React Query or SWR for request deduplication
- - Implement request cancellation
- - Add request queuing
-
-2. **Improve Error Handling**
- - Add retry logic with exponential backoff
- - Implement circuit breaker pattern
- - Add error boundaries
-
-3. **Optimize Caching**
- - Implement stale-while-revalidate pattern
- - Add cache versioning
- - Improve cache invalidation strategy
-
-### Long-term Improvements (Medium Priority)
-
-1. **State Management**
- - Consider Zustand or Redux for global state
- - Centralize notification state
- - Implement optimistic updates
-
-2. **Monitoring & Observability**
- - Add proper logging (Winston/Pino)
- - Implement metrics collection
- - Add performance monitoring
-
-3. **Testing**
- - Add unit tests for hooks
- - Add integration tests for flows
- - Add E2E tests for critical paths
-
----
-
-## 📈 Performance Metrics (Estimated)
-
-### Current Performance Issues:
-
-1. **API Calls**:
- - Estimated 2-3x more calls than necessary due to race conditions
- - No request deduplication
-
-2. **Memory Usage**:
- - Potential memory leaks from uncleaned intervals
- - Closures holding references
-
-3. **Redis Performance**:
- - `KEYS` command can block for seconds with many keys
- - No connection pooling
-
-4. **Bundle Size**:
- - Excessive logging increases bundle size
- - No code splitting for widgets
-
----
-
-## 🔍 Code Quality Metrics
-
-### Code Smells Found:
-
-1. **Long Functions**: Some functions exceed 50 lines
-2. **High Cyclomatic Complexity**: `useNotifications` hook has high complexity
-3. **Duplicate Code**: Similar fetch patterns across widgets
-4. **Magic Numbers**: Hardcoded intervals (300000, 60000, etc.)
-5. **Inconsistent Error Handling**: Different error handling patterns
-
-### Technical Debt:
-
-- **Estimated**: Medium-High
-- **Areas**:
- - Memory management
- - Request management
- - Error handling
- - Caching strategy
- - Logging infrastructure
-
----
-
-## 🛠️ Specific Code Fixes Needed
-
-### Fix 1: useNotifications Hook Cleanup
-
-```typescript
-// BEFORE (Current - Problematic)
-useEffect(() => {
- isMountedRef.current = true;
-
- if (status === 'authenticated' && session?.user) {
- fetchNotificationCount(true);
- fetchNotifications();
- startPolling();
- }
-
- return () => {
- isMountedRef.current = false;
- stopPolling();
- };
-}, [status, session?.user, fetchNotificationCount, fetchNotifications, startPolling, stopPolling]);
-
-// AFTER (Fixed)
-useEffect(() => {
- if (status !== 'authenticated' || !session?.user) return;
-
- isMountedRef.current = true;
-
- // Initial fetch
- fetchNotificationCount(true);
- fetchNotifications();
-
- // Start polling
- const intervalId = setInterval(() => {
- if (isMountedRef.current) {
- debouncedFetchCount();
- }
- }, POLLING_INTERVAL);
-
- // Cleanup
- return () => {
- isMountedRef.current = false;
- clearInterval(intervalId);
- };
-}, [status, session?.user?.id]); // Only depend on primitive values
-```
-
-### Fix 2: Notification Badge Deduplication
-
-```typescript
-// Add request deduplication
-const fetchInProgressRef = useRef(false);
-
-const manualFetch = async () => {
- if (fetchInProgressRef.current) {
- console.log('[NOTIFICATION_BADGE] Fetch already in progress, skipping');
- return;
- }
-
- fetchInProgressRef.current = true;
- try {
- await fetchNotifications(1, 10);
- } finally {
- fetchInProgressRef.current = false;
- }
-};
-```
-
-### Fix 3: Redis SCAN Instead of KEYS
-
-```typescript
-// BEFORE
-const listKeys = await redis.keys(listKeysPattern);
-
-// AFTER
-const listKeys: string[] = [];
-let cursor = '0';
-do {
- const [nextCursor, keys] = await redis.scan(cursor, 'MATCH', listKeysPattern, 'COUNT', 100);
- cursor = nextCursor;
- listKeys.push(...keys);
-} while (cursor !== '0');
-```
-
----
-
-## 📝 Conclusion
-
-The codebase has a solid foundation with good architectural patterns (adapter pattern, separation of concerns), but suffers from several critical issues:
-
-1. **Memory leaks** from improper cleanup
-2. **Race conditions** from lack of request coordination
-3. **Performance issues** from blocking Redis operations
-4. **Error handling gaps** that degrade UX
-
-**Priority**: Fix critical issues immediately, then implement improvements incrementally.
-
-**Estimated Effort**:
-- Critical fixes: 2-3 days
-- High priority improvements: 1-2 weeks
-- Long-term improvements: 1-2 months
-
----
-
-*Generated: Comprehensive codebase analysis*
diff --git a/UNIFIED_REFRESH_SUMMARY.md b/UNIFIED_REFRESH_SUMMARY.md
deleted file mode 100644
index c36a596d..00000000
--- a/UNIFIED_REFRESH_SUMMARY.md
+++ /dev/null
@@ -1,302 +0,0 @@
-# Unified Refresh System - Implementation Summary
-
-## ✅ What Has Been Created
-
-### Core Infrastructure Files
-
-1. **`lib/constants/refresh-intervals.ts`**
- - Standardized refresh intervals for all resources
- - Helper functions for interval management
- - All intervals harmonized and documented
-
-2. **`lib/utils/request-deduplication.ts`**
- - Request deduplication utility
- - Prevents duplicate API calls within 5 seconds
- - Automatic cleanup of stale requests
-
-3. **`lib/services/refresh-manager.ts`**
- - Centralized refresh management
- - Handles all refresh intervals
- - Provides pause/resume functionality
- - Prevents duplicate refreshes
-
-4. **`hooks/use-unified-refresh.ts`**
- - React hook for easy integration
- - Automatic registration/cleanup
- - Manual refresh support
-
-### Documentation Files
-
-1. **`IMPLEMENTATION_PLAN_UNIFIED_REFRESH.md`**
- - Complete architecture overview
- - Detailed implementation guide
- - Code examples for all widgets
-
-2. **`IMPLEMENTATION_CHECKLIST.md`**
- - Step-by-step checklist
- - Daily progress tracking
- - Success criteria
-
----
-
-## 🎯 Next Steps
-
-### Immediate Actions (Start Here)
-
-#### 1. Fix Critical Memory Leaks (30 minutes)
-
-**File**: `lib/services/notifications/notification-service.ts`
-
-Replace `redis.keys()` with `redis.scan()`:
-
-```typescript
-// Line 293 - BEFORE
-const listKeys = await redis.keys(listKeysPattern);
-
-// AFTER
-const listKeys: string[] = [];
-let cursor = '0';
-do {
- const [nextCursor, keys] = await redis.scan(
- cursor,
- 'MATCH',
- listKeysPattern,
- 'COUNT',
- 100
- );
- cursor = nextCursor;
- if (keys.length > 0) {
- listKeys.push(...keys);
- }
-} while (cursor !== '0');
-```
-
----
-
-#### 2. Test Core Infrastructure (1 hour)
-
-Create a test file to verify everything works:
-
-**File**: `lib/services/__tests__/refresh-manager.test.ts` (optional)
-
-Or test manually:
-1. Import refresh manager in a component
-2. Register a test resource
-3. Verify it refreshes at correct interval
-4. Verify cleanup on unmount
-
----
-
-#### 3. Refactor Notifications (2-3 hours)
-
-**File**: `hooks/use-notifications.ts`
-
-Key changes:
-- Remove manual polling logic
-- Use `useUnifiedRefresh` hook
-- Add `requestDeduplicator` for API calls
-- Fix useEffect dependencies
-
-See `IMPLEMENTATION_PLAN_UNIFIED_REFRESH.md` Section 3.1 for full code.
-
----
-
-#### 4. Refactor Notification Badge (1 hour)
-
-**File**: `components/notification-badge.tsx`
-
-Key changes:
-- Remove duplicate `useEffect` hooks
-- Use hook's `refresh` function for manual refresh
-- Remove manual fetch logic
-
----
-
-#### 5. Refactor Navigation Bar Time (30 minutes)
-
-**File**: `components/main-nav.tsx` + `components/main-nav-time.tsx` (new)
-
-Key changes:
-- Extract time display to separate component
-- Use `useUnifiedRefresh` hook (1 second interval)
-- Fix static time issue
-
-See `IMPLEMENTATION_PLAN_UNIFIED_REFRESH.md` Section 3.7 for full code.
-
----
-
-#### 6. Refactor Widgets (1 hour each)
-
-Start with high-frequency widgets:
-1. **Parole** (`components/parole.tsx`) - 30s interval
-2. **Calendar** (`components/calendar.tsx`) - 5min interval
-3. **News** (`components/news.tsx`) - 10min interval
-4. **Email** (`components/email.tsx`) - 1min interval
-5. **Duties** (`components/flow.tsx`) - 2min interval
-
-See `IMPLEMENTATION_PLAN_UNIFIED_REFRESH.md` Section 3.2 for example code.
-
----
-
-## 📊 Expected Results
-
-### Before Implementation:
-- ❌ 120-150 API calls/minute
-- ❌ Memory leaks from uncleaned intervals
-- ❌ Duplicate requests
-- ❌ No coordination between widgets
-
-### After Implementation:
-- ✅ 40-50 API calls/minute (60-70% reduction)
-- ✅ No memory leaks
-- ✅ Request deduplication working
-- ✅ Centralized refresh coordination
-
----
-
-## 🔍 Testing Checklist
-
-After each phase, verify:
-
-- [ ] No console errors
-- [ ] Widgets refresh at correct intervals
-- [ ] Manual refresh buttons work
-- [ ] No duplicate API calls (check Network tab)
-- [ ] No memory leaks (check Memory tab)
-- [ ] Cleanup on component unmount
-- [ ] Multiple tabs don't cause issues
-
----
-
-## 🚨 Important Notes
-
-### Backward Compatibility
-
-All new code is designed to be:
-- ✅ Non-breaking (old code still works)
-- ✅ Gradual migration (one widget at a time)
-- ✅ Easy rollback (keep old implementations)
-
-### Migration Strategy
-
-1. **Phase 1**: Core infrastructure (DONE ✅)
-2. **Phase 2**: Fix critical issues
-3. **Phase 3**: Migrate notifications
-4. **Phase 4**: Migrate widgets one by one
-5. **Phase 5**: Remove old code
-
-### Feature Flags (Optional)
-
-If you want to toggle the new system:
-
-```typescript
-// In refresh manager
-const USE_UNIFIED_REFRESH = process.env.NEXT_PUBLIC_USE_UNIFIED_REFRESH !== 'false';
-
-if (USE_UNIFIED_REFRESH) {
- // Use new system
-} else {
- // Use old system
-}
-```
-
----
-
-## 📈 Performance Monitoring
-
-### Metrics to Track
-
-1. **API Call Count**
- - Before: ~120-150/min
- - Target: ~40-50/min
- - Monitor in Network tab
-
-2. **Memory Usage**
- - Before: Growing over time
- - Target: Stable
- - Monitor in Memory tab
-
-3. **Refresh Accuracy**
- - Verify intervals are correct
- - Check last refresh times
- - Monitor refresh manager status
-
-### Debug Tools
-
-```typescript
-// Get refresh manager status
-const status = refreshManager.getStatus();
-console.log('Refresh Manager Status:', status);
-
-// Get pending requests
-const pendingCount = requestDeduplicator.getPendingCount();
-console.log('Pending Requests:', pendingCount);
-```
-
----
-
-## 🎓 Learning Resources
-
-### Key Concepts
-
-1. **Singleton Pattern**: Refresh manager uses singleton
-2. **Request Deduplication**: Prevents duplicate calls
-3. **React Hooks**: Proper cleanup with useEffect
-4. **Memory Management**: Clearing intervals and refs
-
-### Code Patterns
-
-- **useRef for callbacks**: Prevents dependency issues
-- **Map for tracking**: Efficient resource management
-- **Promise tracking**: Prevents duplicate requests
-
----
-
-## 🐛 Troubleshooting
-
-### Issue: Widgets not refreshing
-
-**Check**:
-1. Is refresh manager started? (`refreshManager.start()`)
-2. Is resource registered? (`refreshManager.getStatus()`)
-3. Is user authenticated? (`status === 'authenticated'`)
-
-### Issue: Duplicate API calls
-
-**Check**:
-1. Is request deduplication working? (`requestDeduplicator.getPendingCount()`)
-2. Are multiple components using the same resource?
-3. Is TTL too short?
-
-### Issue: Memory leaks
-
-**Check**:
-1. Are intervals cleaned up? (check cleanup functions)
-2. Are refs cleared? (`isMountedRef.current = false`)
-3. Are pending requests cleared? (check cleanup)
-
----
-
-## 📝 Next Session Goals
-
-1. ✅ Core infrastructure created
-2. ⏭️ Fix Redis KEYS → SCAN
-3. ⏭️ Refactor notifications hook
-4. ⏭️ Refactor notification badge
-5. ⏭️ Refactor first widget (Parole)
-
----
-
-## 🎉 Success!
-
-Once all widgets are migrated:
-
-- ✅ Unified refresh system
-- ✅ 60%+ reduction in API calls
-- ✅ No memory leaks
-- ✅ Better user experience
-- ✅ Easier maintenance
-
----
-
-*Last Updated: Implementation Summary v1.0*
diff --git a/app/api/missions/test-n8n-config/route.ts b/app/api/missions/test-n8n-config/route.ts
new file mode 100644
index 00000000..5896e2d9
--- /dev/null
+++ b/app/api/missions/test-n8n-config/route.ts
@@ -0,0 +1,139 @@
+import { NextResponse } from 'next/server';
+import { getServerSession } from 'next-auth';
+import { authOptions } from "@/app/api/auth/options";
+import { logger } from '@/lib/logger';
+
+/**
+ * GET /api/missions/test-n8n-config
+ *
+ * Endpoint de test pour vérifier la configuration N8N
+ * Permet de diagnostiquer les problèmes de connexion entre Next.js et N8N
+ *
+ * Authentification: Requise (session utilisateur)
+ */
+export async function GET(request: Request) {
+ try {
+ // Vérifier l'authentification
+ const session = await getServerSession(authOptions);
+ if (!session?.user) {
+ return NextResponse.json(
+ { error: 'Unauthorized' },
+ { status: 401 }
+ );
+ }
+
+ // Récupérer les variables d'environnement
+ const n8nApiKey = process.env.N8N_API_KEY;
+ const n8nWebhookUrl = process.env.N8N_WEBHOOK_URL || 'https://brain.slm-lab.net/webhook/mission-created';
+ const n8nRollbackWebhookUrl = process.env.N8N_ROLLBACK_WEBHOOK_URL || 'https://brain.slm-lab.net/webhook/mission-rollback';
+ const missionApiUrl = process.env.NEXT_PUBLIC_API_URL || 'https://api.slm-lab.net/api';
+ const n8nDeleteWebhookUrl = process.env.N8N_DELETE_WEBHOOK_URL;
+
+ // Construire la réponse
+ const config = {
+ // Variables d'environnement
+ environment: {
+ hasN8NApiKey: !!n8nApiKey,
+ n8nApiKeyLength: n8nApiKey?.length || 0,
+ n8nApiKeyPrefix: n8nApiKey ? `${n8nApiKey.substring(0, 4)}...` : 'none',
+ n8nWebhookUrl,
+ n8nRollbackWebhookUrl,
+ n8nDeleteWebhookUrl: n8nDeleteWebhookUrl || 'not configured',
+ missionApiUrl,
+ },
+
+ // URLs construites
+ urls: {
+ webhookUrl: n8nWebhookUrl,
+ callbackUrl: `${missionApiUrl}/api/missions/mission-created`,
+ rollbackUrl: n8nRollbackWebhookUrl,
+ deleteUrl: n8nDeleteWebhookUrl || 'not configured',
+ },
+
+ // Statut de configuration
+ status: {
+ configured: !!n8nApiKey && !!missionApiUrl,
+ missingApiKey: !n8nApiKey,
+ missingApiUrl: !missionApiUrl,
+ ready: !!n8nApiKey && !!missionApiUrl,
+ },
+
+ // Recommandations
+ recommendations: [] as string[],
+ };
+
+ // Ajouter des recommandations basées sur la configuration
+ if (!n8nApiKey) {
+ config.recommendations.push('❌ N8N_API_KEY n\'est pas défini. Ajoutez-le à vos variables d\'environnement.');
+ } else {
+ config.recommendations.push('✅ N8N_API_KEY est configuré');
+ }
+
+ if (!missionApiUrl) {
+ config.recommendations.push('⚠️ NEXT_PUBLIC_API_URL n\'est pas défini. Utilisation de la valeur par défaut.');
+ } else {
+ config.recommendations.push('✅ NEXT_PUBLIC_API_URL est configuré');
+ }
+
+ if (n8nApiKey && n8nApiKey.length < 10) {
+ config.recommendations.push('⚠️ N8N_API_KEY semble trop court. Vérifiez qu\'il est correct.');
+ }
+
+ // Tester la connectivité au webhook N8N (optionnel, peut être lent)
+ const testWebhook = request.headers.get('x-test-webhook') === 'true';
+ if (testWebhook) {
+ try {
+ logger.debug('Testing N8N webhook connectivity', { url: n8nWebhookUrl });
+ const testResponse = await fetch(n8nWebhookUrl, {
+ method: 'POST',
+ headers: {
+ 'Content-Type': 'application/json',
+ 'x-api-key': n8nApiKey || '',
+ },
+ body: JSON.stringify({ test: true }),
+ signal: AbortSignal.timeout(5000), // 5 secondes timeout
+ });
+
+ config.urls.webhookTest = {
+ status: testResponse.status,
+ statusText: testResponse.statusText,
+ reachable: testResponse.status !== 0,
+ note: testResponse.status === 404
+ ? 'Webhook non enregistré (workflow inactif?)'
+ : testResponse.status === 200 || testResponse.status === 400 || testResponse.status === 500
+ ? 'Webhook actif (peut échouer avec des données de test)'
+ : 'Réponse inattendue',
+ };
+ } catch (error) {
+ config.urls.webhookTest = {
+ error: error instanceof Error ? error.message : 'Unknown error',
+ reachable: false,
+ note: 'Impossible de joindre le webhook N8N',
+ };
+ }
+ } else {
+ config.urls.webhookTest = {
+ note: 'Ajoutez le header "x-test-webhook: true" pour tester la connectivité',
+ };
+ }
+
+ return NextResponse.json({
+ success: true,
+ timestamp: new Date().toISOString(),
+ ...config,
+ });
+ } catch (error) {
+ logger.error('Error in test-n8n-config endpoint', {
+ error: error instanceof Error ? error.message : String(error)
+ });
+ return NextResponse.json(
+ {
+ success: false,
+ error: 'Failed to check N8N configuration',
+ details: error instanceof Error ? error.message : 'Unknown error'
+ },
+ { status: 500 }
+ );
+ }
+}
+
diff --git a/log b/log
deleted file mode 100644
index 8b137891..00000000
--- a/log
+++ /dev/null
@@ -1 +0,0 @@
-