# Guide de Migration des Statuts MedicalRequest

## Vue d'ensemble

Ce guide explique comment utiliser le contrôleur de migration pour mettre à jour les statuts des demandes médicales existantes en fonction du statut de leur paiement associé.

## Nouveaux Statuts

Les demandes médicales utilisent maintenant les statuts suivants :

- `initial` - Demande créée mais pas encore payée
- `en_attente_de_paiement` - Lien de paiement envoyé, en attente du paiement
- `paiement_reussi` - Paiement confirmé avec succès
- `en_attente_de_traitement` - En attente d'assignation ou de traitement par un docteur
- `en_cours` - Docteur travaille sur la demande
- `termine` - Demande traitée et réponse envoyée
- `paiement_echoue` - Paiement échoué
- `annule` - Demande annulée

## Mapping des Statuts

| Ancien Statut Payment | Nouveau Statut MedicalRequest |
|----------------------|-------------------------------|
| `SUCCESSFUL`         | `paiement_reussi`            |
| `PENDING`            | `en_attente_de_paiement`     |
| `FAILED`             | `paiement_echoue`            |
| `CANCELLED`          | `annule`                     |

**Cas spéciaux :**
- Si `medicalRequest.status === "en_cours"` → Reste `en_cours`
- Si `medicalRequest.status === "termine"` → Reste `termine`
- Si `medicalRequest.status === "rejete"` → Devient `annule`

## Configuration

### 1. Ajouter le Token de Migration

Ajoutez la variable d'environnement dans votre fichier conf`.env` :

```bash
MIGRATION_SECRET_TOKEN=your-super-secret-migration-token-here
```

⚠️ **Important :** Utilisez un token fort et unique. Ne le partagez jamais publiquement.

### 2. Générer un Token Fort (optionnel)

```bash
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
```

## Utilisation

### Mode Dry Run (Simulation)

Testez d'abord la migration sans appliquer les changements :

```bash
curl -X POST http://localhost:1337/medical-request/migrate-status \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -d '{
    "data": {
      "dry_run": true,
      "secret_token": "your-super-secret-migration-token-here"
    }
  }'
```

### Mode Production (Modifications Réelles)

Une fois satisfait du dry run, lancez la migration réelle :

```bash
curl -X POST http://localhost:1337/medical-request/migrate-status \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -d '{
    "data": {
      "dry_run": false,
      "secret_token": "your-super-secret-migration-token-here"
    }
  }'
```

## Réponse

### Succès

```json
{
  "success": true,
  "message": "Migration terminée avec succès",
  "dry_run": false,
  "report": {
    "total": 150,
    "updated": 120,
    "skipped": 25,
    "errors": 5
  },
  "details": [
    {
      "id": 1,
      "status": "updated",
      "old_status": "en_attente",
      "new_status": "paiement_reussi",
      "payment_status": "SUCCESSFUL"
    },
    {
      "id": 2,
      "status": "skipped",
      "reason": "Déjà au bon statut",
      "old_status": "termine",
      "new_status": "termine"
    }
  ]
}
```

### Erreurs Possibles

**401 Unauthorized**
```json
{
  "success": false,
  "message": "Token de migration invalide"
}
```

**401 Unauthorized (JWT)**
```json
{
  "error": "Unauthorized"
}
```

**500 Server Error**
```json
{
  "success": false,
  "message": "Erreur lors de la migration",
  "error": "Message d'erreur détaillé"
}
```

## Sécurité

- ✅ Requiert une authentification JWT valide (`is-authenticated`)
- ✅ Requiert un token secret de migration (`secret_token`)
- ✅ Le token est vérifié via la variable d'environnement `MIGRATION_SECRET_TOKEN`
- ⚠️ **Ne jamais commiter le token dans le code source**
- ⚠️ **Changer le token après la migration en production**

## Post-Migration

Après la migration, vous pouvez :

1. **Vérifier les résultats** en utilisant l'endpoint `list-medical-request` avec les nouveaux statuts
2. **Supprimer ou changer** le `MIGRATION_SECRET_TOKEN` dans `.env` pour éviter toute réutilisation accidentelle
3. **Mettre à jour le frontend** pour utiliser les nouveaux statuts

## Rollback (en cas de problème)

Si vous devez annuler la migration :

1. Restaurez une sauvegarde de la base de données
2. OU créez un contrôleur de rollback similaire avec le mapping inverse

## Support

En cas de problème, consultez les logs de l'application :
- Les détails de la migration sont loggés avec des emojis pour faciliter la lecture
- Chaque étape est tracée (✅ succès, ⚠️ ignoré, ❌ erreur)

## Notes Importantes

- Cette migration est **idempotente** : elle peut être exécutée plusieurs fois sans danger
- Les statuts `en_cours` et `termine` sont **préservés** (logique métier)
- Les demandes sans paiement associé sont **ignorées**
- Le mode `dry_run` ne modifie **aucune donnée** et permet de prévisualiser les changements