# Migration rétroactive des contract_id dans email_logs

## Problème

Les emails de signature électronique envoyés **avant la modification** n'ont pas de `contract_id` enregistré dans la table `email_logs`. Cela empêche l'affichage des notifications passées dans la colonne "Notif." de la page staff/contrats.

## Solution

Ce script de migration analyse les emails de signature existants et remplit rétroactivement le champ `contract_id` en utilisant les données du `template_data`.

## Comment l'utiliser

### Option 1 : Via l'éditeur SQL de Supabase (Recommandé)

1. Connectez-vous à votre projet Supabase
2. Allez dans **SQL Editor**
3. Copiez-collez le contenu du fichier `002_backfill_contract_ids_in_email_logs.sql`
4. Cliquez sur **Run**
5. Vérifiez les logs qui affichent le nombre d'emails mis à jour

### Option 2 : Via la CLI Supabase

```bash
supabase db execute --file supabase/migrations/002_backfill_contract_ids_in_email_logs.sql
```

## Ce que fait le script

1. **Parcourt** tous les emails de type signature (`signature-request-employer`, `signature-request-employee`, `signature-request-salarie`) qui n'ont pas de `contract_id`

2. **Extrait** la référence du contrat depuis le `template_data` :
   - `contractReference`
   - `contract_number`
   - `reference`

3. **Recherche** le contrat correspondant dans la table `cddu_contracts`

4. **Met à jour** le champ `contract_id` dans `email_logs`

5. **Affiche** des statistiques finales

## Résultats attendus

Après l'exécution, vous devriez voir :

```
Début de la migration des contract_id dans email_logs...
Progression: 100 emails mis à jour...
Progression: 200 emails mis à jour...
Migration terminée: 247 emails mis à jour avec leur contract_id

Statistiques après migration:
- Emails de signature avec contract_id: 247
- Emails de signature sans contract_id: 12
```

Les emails qui restent sans `contract_id` sont probablement :
- Des emails de test
- Des emails pour des contrats supprimés
- Des emails avec des données incomplètes

## Vérification

Pour vérifier manuellement :

```sql
-- Voir les emails de signature avec leur contract_id
SELECT 
  el.id,
  el.email_type,
  el.recipient_email,
  el.created_at,
  el.contract_id,
  c.contract_number
FROM email_logs el
LEFT JOIN cddu_contracts c ON c.id = el.contract_id
WHERE el.email_type IN ('signature-request-employer', 'signature-request-employee', 'signature-request-salarie')
ORDER BY el.created_at DESC
LIMIT 20;
```

## Impact

- ✅ **Sécurité** : Lecture seule puis UPDATE uniquement sur `contract_id`
- ✅ **Performance** : Indexé sur `contract_id` après migration
- ✅ **Rollback** : Peut être annulé en mettant `contract_id` à NULL
- ✅ **Idempotent** : Peut être exécuté plusieurs fois sans problème

## Rollback (si nécessaire)

Si vous voulez annuler la migration :

```sql
UPDATE email_logs
SET contract_id = NULL
WHERE email_type IN ('signature-request-employer', 'signature-request-employee', 'signature-request-salarie')
  AND contract_id IS NOT NULL;
```

## Après la migration

Une fois la migration exécutée, la colonne "Notif." dans `/staff/contrats` affichera **toutes** les notifications passées et futures pour chaque contrat.