# TRAIL DPS 4.2 - LOT 5.0.1 OVH - Normalisation COURSE_STAFF

## Objectif

Corriger le modele serveur avant le LOT 5.1 PLACE : le serveur ne doit plus figer les roles `OPENER` / `CLOSER` dans les devices, bindings ou positions.

Le role ouvreur/fermeur sera resolu dans PLACE a partir :

- du planning des affectations de portions ;
- puis, plus tard, d'un override manuel LIVE DPS si l'operateur force temporairement le role.

## Actor types serveur cibles

Valeurs autorisees apres ce lot :

- `RESCUE` : equipes secours ;
- `SECURITY` : equipes securite ;
- `COURSE_STAFF` : acteurs course pouvant etre ouvreur ou fermeur selon le planning PLACE ;
- `UNKNOWN` : fallback technique.

`OPENER` et `CLOSER` sont epures cote serveur. Ils ne doivent plus etre envoyes par PLACE pour l'enrolement mobile.

## Fichiers modifies

- `SRC/Tracking/TrackingValidation.php`
- `SRC/Tracking/TrackingHttp.php`
- `public/api/tracking/create_device_activation.php`
- `sql/tracking_schema.sql`
- `sql/lot6_device_activation_tokens.sql`

## Fichiers crees

- `sql/lot_5_0_1_course_staff_actor_type.sql`
- `docs/LOT_5_0_1_MODIFICATIONS.md`

## Changements techniques

### Validation actor_type

La liste serveur devient :

```text
RESCUE, SECURITY, COURSE_STAFF, UNKNOWN
```

La methode `roleActorType()` mappe maintenant :

```text
OPENER / CLOSER / OUVREUR / FERMEUR -> COURSE_STAFF
SECOURS -> RESCUE
SECURITE / SECURITY -> SECURITY
```

### Activation mobile

`create_device_activation.php` exige maintenant :

- `local_team_id` pour `RESCUE` et `SECURITY` ;
- `local_staff_team_id` pour `COURSE_STAFF`.

L'en-tete `X-Activation-Secret` est obligatoire pour creer un token d'activation.

### Migration SQL

Le script `sql/lot_5_0_1_course_staff_actor_type.sql` :

1. ajoute temporairement `COURSE_STAFF` tout en conservant `OPENER/CLOSER` ;
2. convertit les donnees existantes `OPENER/CLOSER` vers `COURSE_STAFF` ;
3. retire definitivement `OPENER/CLOSER` des ENUM ;
4. fournit une requete de verification finale.

## Procedure d'integration

1. Sauvegarder la base `synoluidpstrack`.
2. Deployer les fichiers PHP modifies sur OVH.
3. Executer `sql/lot_5_0_1_course_staff_actor_type.sql` sur la base tracking.
4. Verifier que la requete finale retourne 0 pour toutes les tables.
5. Tester `create_device_activation.php` avec :
   - `actor_type = RESCUE` + `local_team_id` ;
   - `actor_type = SECURITY` + `local_team_id` ;
   - `actor_type = COURSE_STAFF` + `local_staff_team_id`.

## Exemple PowerShell cible COURSE_STAFF

```powershell
$body = @{
    place_instance_id = "PLACE-TEST"
    event_remote_id = "EVT-TEST"
    event_local_id = 2026
    run_id = $null
    event_name = "EVT-TEST"
    actor_type = "COURSE_STAFF"
    actor_label = "Equipe ouvreur/fermeur 1"
    device_uid = "IOS-TEST-1"
    device_label = "Equipe ouvreur/fermeur 1"
    local_team_id = $null
    local_staff_team_id = 7
} | ConvertTo-Json -Depth 5

Invoke-RestMethod `
    -Uri "https://tracking.synoluvia.fr/api/tracking/create_device_activation.php" `
    -Method POST `
    -Headers @{
        "X-Api-Key" = $publicApiKey
        "X-Activation-Secret" = $activationSecret
    } `
    -ContentType "application/json; charset=utf-8" `
    -Body $body
```

## Points de vigilance

- Ne plus creer de QR mobile avec `actor_type = OPENER` ou `actor_type = CLOSER`.
- Ne pas calculer le role ouvreur/fermeur sur OVH.
- Le role LIVE sera calcule dans PLACE, puis surchargeable manuellement dans LIVE DPS dans un futur lot.
- Ne pas melanger `SECURITY` avec `RESCUE` : les deux utilisent `local_team_id`, mais restent deux categories distinctes.