# Test du système de backup / restauration tenant

## Vue d'ensemble

Ce guide décrit comment tester le cycle complet **sauvegarde → purge → restauration** pour un tenant, en utilisant un compte test créé automatiquement par des commandes Artisan.

Le système restaure les données avec leurs **IDs originaux** (pas de décalage), ce qui garantit la cohérence des relations FK.

---

## Commandes disponibles

### `tenant:seed-test` — Créer les données de test

Crée un utilisateur test et peuple toutes les tables tenant avec des données factices.

```bash
php artisan tenant:seed-test
```

**Options :**

| Option | Défaut | Description |
|--------|--------|-------------|
| `--email` | `test@test.com` | Email du compte test |
| `--password` | `testeur` | Mot de passe du compte test |
| `--count` | `3` | Nombre de lignes par table |

**Exemples :**
```bash
# Utilisation basique
php artisan tenant:seed-test

# Personnaliser l'email et le nombre de lignes
php artisan tenant:seed-test --email=demo@demo.com --count=5

# Mot de passe personnalisé
php artisan tenant:seed-test --password=monmotdepasse
```

**Ce que fait la commande :**
1. Crée (ou récupère) l'utilisateur `test@test.com`
2. Découvre automatiquement toutes les tables tenant (colonne `user_id`)
3. Résout les dépendances FK entre tables (tri topologique)
4. Insère `--count` lignes par table dans le bon ordre
5. Affiche les IDs créés par table

**Sortie exemple :**
```
👤 Utilisateur test : test@test.com (id=42)
🔍 Tables tenant découvertes : 23
📐 Ordre d'insertion résolu.
📋 Création de 3 ligne(s) par table...
  ✔ forets               → 101, 102, 103
  ✔ cartes               → 201, 202, 203
  ✔ parcelles            → 301, 302, 303
  ✔ plans_de_gestion     → 401, 402, 403
  ✔ operations           → 501, 502, 503
  ...
✅ 69 lignes créées dans 23 table(s).
   Connectez-vous en tant que test@test.com (mot de passe : testeur)
   puis effectuez une sauvegarde via l'interface.
```

---

### `tenant:purge-test` — Supprimer les données test

Supprime toutes les données du compte test **sans supprimer le compte lui-même**.

```bash
php artisan tenant:purge-test
```

**Options :**

| Option | Défaut | Description |
|--------|--------|-------------|
| `--email` | `test@test.com` | Email du compte dont les données sont supprimées |

**Exemples :**
```bash
# Purge standard
php artisan tenant:purge-test

# Purge d'un email personnalisé
php artisan tenant:purge-test --email=demo@demo.com
```

**Ce que fait la commande :**
1. Localise l'utilisateur test
2. Demande confirmation (prompt interactif)
3. Désactive les FK checks (`SET FOREIGN_KEY_CHECKS=0`)
4. Supprime toutes les lignes `WHERE user_id = {id}` dans chaque table tenant
5. Réactive les FK checks
6. Conserve le compte utilisateur intact

> **⚠ La commande demande une confirmation avant de supprimer. Répondez `yes` pour confirmer.**

---

## Scénario de test complet

### Prérequis
- Accès à l'application (URL et identifiants admin)
- Terminal avec accès `php artisan`
- Sauvegarde de la base de production effectuée

### Étapes

**1. Créer les données test**
```bash
php artisan tenant:seed-test
```
Notez les IDs affichés dans la sortie (ex : forets 101, 102, 103).

**2. Connexion et vérification**
- Connectez-vous à l'application avec `test@test.com` / `testeur`
- Vérifiez que les données apparaissent correctement dans les différentes sections

**3. Créer une sauvegarde**
- Dans l'application : **Sauvegardes → Créer une sauvegarde**
- Téléchargez le fichier ZIP généré

**4. Purger les données test**
```bash
php artisan tenant:purge-test
# → Confirmer avec 'yes'
```
Reconnectez-vous : l'interface doit être vide.

**5. Restaurer la sauvegarde**
- Dans l'application : **Sauvegardes → Uploader une sauvegarde**
- Uploadez le ZIP téléchargé à l'étape 3
- Cliquez sur **Restaurer**

**6. Vérifier la restauration**

| Critère | Attendu |
|---------|---------|
| Données visibles | Identiques à celles créées à l'étape 1 |
| IDs des lignes | **Identiques** aux IDs originaux (101, 102...) |
| Relations FK | Cohérentes (opérations liées aux bonnes forêts, etc.) |
| Autres utilisateurs | **Non affectés** (leurs données sont intactes) |

---

## Architecture technique

### Découverte tenant-agnostique

Les commandes détectent automatiquement les tables tenant via :
```sql
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE() AND COLUMN_NAME = 'user_id'
```

Cela les rend **compatibles avec tout site utilisant ce système de tenant**, quelle que soit la liste des tables.

### Tables exclues automatiquement

Les tables suivantes sont toujours exclues (tables système) :
`migrations`, `jobs`, `cache`, `sessions`, `users`, `backups`, `modules`,
`tarifs`, `tarif_types`, `sylvicultural_rules`, `sylvicultural_programs`, etc.

### Résolution des dépendances FK

Les commandes résolvent les FK en deux passes :
1. **Contraintes formelles** via `INFORMATION_SCHEMA.KEY_COLUMN_USAGE`
2. **Convention de nommage** : colonnes `id_*` → table correspondante
   - `id_foret` → `forets`
   - `id_operation` → `operations`
   - `id_plan_gestion` → `plans_de_gestion` (premier mot : `plan` → `plans_*`)

### Conservation des IDs à la restauration

Le `JsonRestoreListener` utilise `insertOrIgnore` avec les IDs originaux :
- **Pas d'offset** appliqué
- Si un ID est déjà pris (rare, conflit avec autre tenant), la ligne est ignorée
- Les relations FK internes sont garanties cohérentes

---

## Utilisation sur d'autres sites

Ces commandes fonctionnent sur **tout site utilisant le système de tenant avec colonne `user_id`**. La seule adaptation nécessaire est la liste `SYSTEM_TABLES` dans chaque commande, si votre site a des tables système supplémentaires à exclure.

```bash
# Copier les commandes vers un autre site
cp app/Console/Commands/TenantSeedTest.php  /path/to/autre-site/app/Console/Commands/
cp app/Console/Commands/TenantPurgeTest.php /path/to/autre-site/app/Console/Commands/
```

---

## Dépannage

| Problème | Solution |
|----------|----------|
| `❌ Utilisateur introuvable` | L'email n'existe pas. Lancez d'abord `tenant:seed-test` |
| Erreur FK à l'insertion | Une table parent n'a pas encore de données. Vérifiez le tri topologique |
| Données non restaurées | Vérifiez que le backup appartient bien au compte test (même `user_id`) |
| ID en conflit à la restauration | Un autre utilisateur a créé une ligne avec le même ID entre la purge et la restauration. C'est extrêmement rare en test local |
| La commande ne trouve aucune table | Vérifiez que la base est accessible et que `DATABASE()` retourne le bon schema |