# Purge et seed — Phase 2 (système vierge)

Les données existantes sont des données de test. On purge la base et on repart à zéro avec les préinscriptions. Aucune stratégie de migration pour les anciens comptes "guest".

---

## Tables à purger (ordre pour respect des clés étrangères)

On vide les tables dans l’ordre suivant (pour ne pas violer les FK). On ne supprime pas la structure, uniquement les données.

| Ordre | Table | Raison |
|-------|--------|--------|
| 1 | `payments` | FK vers registrations, contributions, payment_batches, users |
| 2 | `registration_status_changes` | FK vers registrations |
| 3 | `contributions` | FK vers users, events, payment_batches |
| 4 | `payment_batches` | FK vers users |
| 5 | `public_registration_tokens` | FK vers registrations |
| 6 | `account_activation_tokens` | FK vers users (table ajoutée en Phase 2) |
| 7 | `recommendations` | FK vers events (pas vers users) |
| 8 | `registrations` | FK vers users, events, pricing_plans, payment_batches |
| 9 | `model_has_roles` | Spatie — lien user ↔ role |
| 10 | `model_has_permissions` | Spatie — lien user ↔ permission (si utilisé) |
| 11 | `personal_access_tokens` | Sanctum — tokens de connexion |
| 12 | `users` | — |

**Tables non purgées :**  
`events`, `event_phases`, `pricing_plans`, `event_settings`, `roles`, `permissions`, `role_has_permissions` (on réinitialise les rôles/permissions dans le seed, voir ci‑dessous).

---

## Stratégie de seed

### 1. Réinitialiser les rôles et permissions (optionnel selon approche)

- Soit on **truncate** `role_has_permissions`, `model_has_roles`, `model_has_permissions`, puis `roles`, `permissions`, et on recrée tout dans le seed.
- Soit on **supprime** uniquement les rôles/permissions existants par nom et on recrée les nouveaux (pour éviter de casser une config Spatie déjà en place).  
Recommandation : **truncate** (système vierge) dans l’ordre : `role_has_permissions` → `model_has_roles` → `model_has_permissions` → `roles` → `permissions`.

### 2. Rôles à créer

Droits d'accès basés sur l'événement et le rôle (plus de Sommet, uniquement événements ex. Séminaire national de mars 2026).

- `SUPER_ADMIN`
- `COMMISSION_ADMINISTRATION`
- `COMMISSION_FINANCE`
- `COMMISSION_COMMUNICATION`
- `FACILITATEUR` (remplace Commission Séminaire Régional)
- `guest` (créé à l’inscription publique, pas de login)
- `participant` (après activation du compte)

(Optionnel : garder `delegate_lead` si utilisé ailleurs ; sinon à recréer si besoin.)

### 3. Permissions à créer (atomiques)

- **Inscriptions :** `registrations.read`, `registrations.update`, `registrations.update_status`, `registrations.delete`, `registrations.export`
- **Recommandations :** `recommendations.read`, `recommendations.update_status`, `recommendations.send_email`
- **Finance :** `payments.read`, `payments.confirm`, `batches.read`, `batches.mark_paid`, `exports.finance`
- **Communication :** `messages.send` (si besoin)

### 4. Attribution rôle → permissions

- **SUPER_ADMIN** : toutes les permissions.
- **COMMISSION_ADMINISTRATION** : registrations.*, recommendations.* (pas exports.finance, pas payments.confirm/batches.mark_paid).
- **COMMISSION_FINANCE** : registrations.read, payments.*, batches.*, exports.finance.
- **COMMISSION_COMMUNICATION** : registrations.read (éventuellement limité), recommendations.read, recommendations.send_email, messages.send.
- **FACILITATEUR** : registrations.read, registrations.update (éventuellement filtré par événement), recommendations.read, recommendations.update_status, recommendations.send_email.
- **guest** : aucune (pas de login).
- **participant** : aucune permission admin (accès uniquement à ses propres données via API dédiée).

### 5. Comptes à créer (users)

| Compte | Email (exemple) | Rôle | Mot de passe |
|--------|------------------|------|--------------|
| Super Admin | `superadmin@haggai-bf.org` (ou depuis `.env`) | SUPER_ADMIN | Depuis `.env` ou valeur par défaut (dev) |
| Commission Administration | `commission.administration@haggai-bf.org` | COMMISSION_ADMINISTRATION | Depuis `.env` ou défaut |
| Commission Finance | `commission.finance@haggai-bf.org` | COMMISSION_FINANCE | Depuis `.env` ou défaut |
| Commission Communication | `commission.communication@haggai-bf.org` | COMMISSION_COMMUNICATION | Depuis `.env` ou défaut |
| Facilitateur | `facilitateur@haggai-bf.org` | FACILITATEUR | Depuis `.env` (`SEED_FACILITATEUR_EMAIL`, `SEED_FACILITATEUR_PASSWORD`) ou défaut |

Les mots de passe peuvent être lus depuis des variables d’environnement (`SEED_SUPER_ADMIN_PASSWORD`, etc.) avec un fallback pour l’environnement local Par défaut : nom du rôle/commission + `456` (ex. `superadmin456`, `administration456`, `finance456`, `communication456`, `facilitateur456`). Surcharge possible via `.env`.

### 6. Ordre d’exécution du seed

1. **PurgeSeeder** (ou première partie du DatabaseSeeder) : truncate des tables listées ci‑dessus dans l’ordre.
2. **CommissionRolesSeeder** (ou équivalent) : création des permissions, création des rôles, attribution des permissions aux rôles.
3. **CommissionUsersSeeder** (ou équivalent) : création des 6 users staff et assignation des rôles (SUPER_ADMIN + 4 commissions + Facilitateur).

---

## Commandes après implémentation

```bash
# Purge + seed complet (à exécuter après migration)
php artisan db:seed --class=PurgeSeeder
php artisan db:seed --class=CommissionRolesSeeder
php artisan db:seed --class=CommissionUsersSeeder

# Ou un seul seeder qui enchaîne tout
php artisan db:seed --class=Phase2FreshStartSeeder
```

---

Ce document sert de référence pour l’implémentation des seeders et la documentation des opérations de purge.