-- L'historique d'une intervention, pour trancher les litiges.
--
-- POURQUOI PAS journal_audit. Il existe, mais il repond a une autre question : « qui a
-- touche a quoi », avec l'adresse IP, pour un administrateur. Les creations d'intervention
-- y sont d'ailleurs rattachees au BIEN, parce qu'elles se font par lots — la ligne
-- « demandee le X par Y » y serait introuvable pour une intervention donnee.
--
-- Ici la question se pose devant un client qui conteste : « que s'est-il passe sur cette
-- prestation, et qui l'a decide ». Cela demande un recit attache a l'intervention, complet,
-- et lisible par le client lui-meme.
--
-- APPEND-ONLY. Aucun UPDATE, aucun DELETE hors la cascade : une ligne qu'on pourrait
-- reecrire ne vaudrait rien le jour ou elle sert de preuve. Les corrections s'ajoutent.

CREATE TABLE intervention_evenements (
    id              BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    intervention_id BIGINT UNSIGNED NOT NULL,

    -- Le vocabulaire est celui de App\Domain\EvenementIntervention. VARCHAR et non ENUM :
    -- un evenement s'ajoute au fil des fonctions, et un ALTER sur une table qui grossit
    -- indefiniment se paie. La valeur inconnue est ignoree a la lecture.
    type            VARCHAR(40)     NOT NULL,

    -- L'auteur, en DEUX colonnes et c'est volontaire.
    --
    -- acteur_id pointe vers le compte, et vaut NULL quand c'est la synchronisation iCal
    -- qui ecrit. acteur_libelle fige le nom AU MOMENT DES FAITS : un compte se renomme, se
    -- desactive, change de main. Un historique qui afficherait le nom actuel raconterait
    -- une autre histoire que celle qui s'est produite, et c'est exactement ce qu'un litige
    -- viendrait contester.
    acteur_id       BIGINT UNSIGNED NULL,
    acteur_libelle  VARCHAR(160)    NULL,

    -- Le role au moment des faits, pour la meme raison : « valide par le concierge » ne se
    -- deduit pas du role actuel du compte.
    acteur_role     VARCHAR(20)     NULL,

    -- L'ecart, en JSON : {"champ": {"avant": ..., "apres": ...}}. Du texte libre serait
    -- plus simple a ecrire et impossible a relire proprement.
    details         TEXT            NULL,

    -- Une phrase deja redigee, quand l'evenement en merite une (le compte rendu du
    -- prestataire, le motif d'un refus). Elle s'affiche telle quelle.
    commentaire     TEXT            NULL,

    cree_le         DATETIME        NOT NULL,

    PRIMARY KEY (id),

    -- L'index qui porte la lecture : tout l'historique d'une intervention, dans l'ordre.
    KEY idx_evt_intervention (intervention_id, cree_le),

    -- CASCADE : l'historique d'une intervention supprimee n'a plus d'objet. Les
    -- interventions ne se suppriment que lorsqu'une demande est retiree avant validation
    -- — une intervention arbitree, elle, change de statut et reste.
    CONSTRAINT fk_evt_intervention FOREIGN KEY (intervention_id)
        REFERENCES interventions (id) ON DELETE CASCADE,

    -- SET NULL et non CASCADE : si le compte disparait, la ligne d'historique reste, et
    -- acteur_libelle continue de dire qui c'etait. C'est tout l'interet des deux colonnes.
    CONSTRAINT fk_evt_acteur FOREIGN KEY (acteur_id)
        REFERENCES utilisateurs (id) ON DELETE SET NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
