# Aligner la config CHAPS d'un environnement sur un autre (ex. staging ← local)

## Pourquoi

L'interface d'Estair Connect (KPI/badges, cartes de filtrage, colonnes de liste,
champs de la vue détail, CTAs, navigation) est **entièrement pilotée par la config
CHAPS** stockée dans la base CHAPS (`badges`, `metadatas`, `metadatas_generated`,
`blocs`, `ctas`, `menus`, `modules`, `domaines`, `picklists`, `colors`, `dashboards`).
Le **front** et le **backend estair** sont identiques d'un environnement à l'autre ;
seule cette config (et les données) diffère. Deux CHAPS peuvent donc **diverger**
(ex. le local a les badges `pnr` ; le staging a `account_id` activé en liste), d'où
des interfaces différentes **à compte identique**.

Ces deux commandes permettent de **répliquer la config d'un CHAPS sur un autre**,
sans toucher aux données tenant ni aux comptes/rôles.

## Ce qui est synchronisé / exclu

- **Synchronisé** (cf. `ExportConfigCommand::CONFIG_TABLES`) : `domaines`, `modules`,
  `menus`, `blocs`, `badges`, `ctas`, `ctas_enum`, `picklists`, `colors`, `dashboards`.
- **JAMAIS touché** :
  - `metadatas` **et** `metadatas_generated` → **propres à chaque environnement**
    (flags de champs list/detail/is_active, JSON généré). Exclus de l'export **et**
    protégés à l'import (ignorés même si présents dans un ancien fichier).
  - données métier (etatsdeventes, pnr, …), **auth** (`users`, `roles`, `users_roles`,
    tokens), runtime (`badge_cache`, `badge_alerts` — vidés, pas copiés), tables
    `*_backup`, `badges_2`, `old_dashboards`.

> Conséquence : cet outil aligne les **KPI/badges, CTAs, menus, blocs, picklists,
> couleurs, dashboards** — mais **PAS** la config des **champs/colonnes** (`metadatas`),
> qui reste gérée par environnement (ex. l'activation `list=1` de `account_id`).
>
> Remarque : les permissions **rôle → modules** (lues par estair via
> `/internal/roles/{role}/modules`) ne sont **pas** dans ce périmètre (liées à l'auth).

## Procédure (staging ← local)

### 1. Exporter la config depuis le LOCAL
Dans le dossier `chaps` local (base `chaps`) :
```bash
php artisan chaps:config:export
# → storage/app/chaps-config-YYYYMMDD_HHMMSS.json
```
Restreindre à certaines tables si besoin (ex. seulement les KPI/badges) :
```bash
php artisan chaps:config:export --tables=badges,blocs
```

### 2. Copier le fichier sur le serveur STAGING
```bash
scp storage/app/chaps-config-*.json user@staging:/chemin/chaps/storage/app/
```

### 3. Importer sur STAGING
Dans le dossier `chaps` de staging (base `ceterisprime_chaps`) :
```bash
php artisan chaps:config:import chaps-config-YYYYMMDD_HHMMSS.json
```
- Un **backup JSON** de l'état courant est écrit dans `storage/app/` avant écrasement
  (réversible : `php artisan chaps:config:import chaps-config-backup-*.json --force`).
- Remplacement **transactionnel** (rollback si erreur).
- `--force` pour sauter la confirmation (déploiement automatisé) ;
  `--no-backup` pour sauter la sauvegarde (déconseillé).

### 4. Purger les caches (sinon l'ancienne config persiste)
```bash
# a) Cache CHAPS runtime déjà vidé par l'import (badge_cache, badge_alerts).
# b) Cache estair (dossier estair sur staging) — lit badges/metadatas avec TTL :
php artisan cache:clear
```

### 5. Navigateur (PWA)
Le service worker sert encore l'ancien SPA depuis le cache. Pour voir le résultat :
navigation privée, **ou** F12 → Application → Service Workers → *Unregister* +
*Clear storage* → Ctrl+Shift+R. (Même rappel que `frontend/deploy.sh`.)

## Sécurité & réversibilité

- Rien n'est supprimé sans **backup** préalable (sauf `--no-backup`).
- Périmètre **strictement config** : aucune donnée métier ni compte utilisateur touché.
- Le sens est **cible ← source** : l'environnement importé devient une **copie** de la
  config source. Choisir la bonne source de vérité avant d'importer.

## Vérification

- `php artisan chaps:config:export` en local : contrôler le récap (nb de lignes par
  table) et la présence du fichier.
- Après import sur staging : recharger `/app/vente/pnr` (nav privée) → mêmes KPI/badges
  et mêmes colonnes qu'en local. Le champ « Compte » suit désormais la même config.
