# Mises à jour BDD Syndic pour la production

Ce document recense les changements BDD identifiés à partir du commit `eca5707` (`setup syndic Codeigniter 4`) jusqu'à `HEAD`, plus la migration locale non encore commitée `2026-05-27-000001_AddTachAscToTaches.php`.

Objectif: pouvoir appliquer les changements directement en SSH avec le client `mysql`, sans dépendre des commandes CI4.

## Ordre recommandé

1. Appliquer les `ALTER TABLE` sur les colonnes manquantes.
2. Créer la table `tech_uti`.
3. Insérer les liaisons `tech_uti`.
4. Traiter les comptes utilisateurs à migrer vers `utiPassHash`.

## 1) `utilisateurs.utiPassHash`

Migration CI4: `2026-05-23-000001_AddUtiPassHashToUtilisateurs.php`

Commande MySQL:

```sql
ALTER TABLE `utilisateurs`
  ADD COLUMN `utiPassHash` VARCHAR(255) NULL AFTER `utiPass`;
```

## 2) `utilisateurs.utiSyn`

Migration CI4: `2026-05-24-000001_AddUtiSynToUtilisateurs.php`

Commande MySQL:

```sql
ALTER TABLE `utilisateurs`
  ADD COLUMN `utiSyn` INT NULL AFTER `utiDroit`;
```

## 3) `payements.pay_etat` et `payements.pay_etat_date`

Migration CI4: `2026-05-25-000001_AddPayEtatAndTechUti.php`

Commandes MySQL:

```sql
ALTER TABLE `payements`
  ADD COLUMN `pay_etat` TINYINT(1) NOT NULL DEFAULT 0 AFTER `pay_realisee`;

ALTER TABLE `payements`
  ADD COLUMN `pay_etat_date` DATETIME NULL AFTER `pay_etat`;
```

## 4) Table `tech_uti`

Migration CI4: `2026-05-25-000001_AddPayEtatAndTechUti.php`

Commande MySQL:

```sql
CREATE TABLE `tech_uti` (
  `tu_id` INT NOT NULL AUTO_INCREMENT,
  `tu_tech` INT NOT NULL,
  `tu_uti` INT NOT NULL,
  PRIMARY KEY (`tu_id`),
  KEY `idx_tech_uti_uti` (`tu_uti`),
  KEY `idx_tech_uti_tech` (`tu_tech`)
);
```

## 5) Liaison technicien / utilisateur

Seeder CI4: `App\Database\Seeds\TechUtiSeeder`

Lignes à insérer:

```sql
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (2, 39);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (3, 41);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (4, 36);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (1, 40);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (5, 39);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (5, 41);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (8, 40);
INSERT INTO `tech_uti` (`tu_tech`, `tu_uti`) VALUES (8, 41);
```

## 6) `taches.tach_pay`

Migration CI4: `2026-05-25-000002_AddTachPayToTaches.php`

Commande MySQL:

```sql
ALTER TABLE `taches`
  ADD COLUMN `tach_pay` INT NOT NULL DEFAULT 0 AFTER `tach_date_fin`;
```

## 7) `taches.tach_fact`

Migration CI4: `2026-05-25-000003_AddTachFactToTaches.php`

Commande MySQL:

```sql
ALTER TABLE `taches`
  ADD COLUMN `tach_fact` INT NOT NULL DEFAULT 0 AFTER `tach_pay`;
```

## 8) `taches.tach_cont`

Migration CI4: `2026-05-25-000004_AddTachContToTaches.php`

Commande MySQL:

```sql
ALTER TABLE `taches`
  ADD COLUMN `tach_cont` INT NOT NULL DEFAULT 0 AFTER `tach_fact`;
```

## 9) `taches.tach_asc`

Migration locale non commitée: `2026-05-27-000001_AddTachAscToTaches.php`

Commande MySQL:

```sql
ALTER TABLE `taches`
  ADD COLUMN `tach_asc` INT NOT NULL DEFAULT 0 AFTER `tach_cont`;
```

## 10) Migration des mots de passe legacy vers `utiPassHash`

Command CI4 liées au code:

- `php spark users:hashpasswords`

Limite importante: cette opération ne peut pas être reproduite proprement en SQL pur, car elle dépend d'un hash bcrypt généré pour chaque mot de passe existant.

Si la production ne permet vraiment que `mysql`, il faut alors préparer en amont un `UPDATE` par utilisateur avec la valeur de `utiPassHash` déjà calculée, par exemple:

```sql
UPDATE `utilisateurs`
SET `utiPassHash` = '<hash_bcrypt>'
WHERE `utiId` = <id_utilisateur>;
```

## 11) Création d'un compte syndic CI4

Commande CI4 liée au code:

- `php spark syndic:create-login <mail> <password> <syn_id> [name]`

Comme pour la migration des mots de passe, cette création ne se traduit pas en SQL brut sans connaître à l'avance la valeur du hash `password_hash()`. En SQL pur, l'équivalent minimal est:

```sql
INSERT INTO `utilisateurs` (`utiNom`, `utiMail`, `utiPass`, `utiPassHash`, `utiDroit`, `utiSyn`)
VALUES ('Nom affiché', 'mail@example.tld', '', '<hash_bcrypt>', 5, <syn_id>);
```

## Vérification rapide

Avant d'exécuter un `ALTER TABLE`, tu peux vérifier si la colonne existe déjà:

```sql
SHOW COLUMNS FROM `utilisateurs` LIKE 'utiPassHash';
SHOW COLUMNS FROM `utilisateurs` LIKE 'utiSyn';
SHOW COLUMNS FROM `payements` LIKE 'pay_etat';
SHOW COLUMNS FROM `payements` LIKE 'pay_etat_date';
SHOW COLUMNS FROM `taches` LIKE 'tach_pay';
SHOW COLUMNS FROM `taches` LIKE 'tach_fact';
SHOW COLUMNS FROM `taches` LIKE 'tach_cont';
SHOW COLUMNS FROM `taches` LIKE 'tach_asc';
SHOW TABLES LIKE 'tech_uti';
```

## Résumé des changements BDD détectés

- `utilisateurs`: ajout de `utiPassHash` et `utiSyn`.
- `payements`: ajout de `pay_etat` et `pay_etat_date`.
- `tech_uti`: nouvelle table de liaison technicien/utilisateur.
- `taches`: ajout de `tach_pay`, `tach_fact`, `tach_cont`, `tach_asc`.
- Données: insertion des liaisons `tech_uti` et migration des mots de passe vers `utiPassHash`.