-- Le canal devient reglable, et une notification peut se masquer.
--
-- CE QUE CETTE MIGRATION CORRIGE, ET C'ETAIT UN DEFAUT DE CONCEPTION, PAS UNE LIMITE.
--
-- notification_reglages portait un BOOLEEN : informer, ou pas. Le canal — fil seul, ou fil et
-- courriel — etait deduit du seul classement du domaine, donc impose. Un concierge qui trouvait
-- une alerte trop bruyante n'avait qu'une issue : decocher la case, ce qui supprimait AUSSI la
-- ligne de fil. Le seul moyen de reduire les courriels etait de detruire de l'information.
--
-- L'ecran allait jusqu'a expliquer cette contrainte au concierge (« ce n'est pas un reglage de
-- courriel, c'est un reglage d'information ») — c'etait habiller une limite en principe. La
-- bonne reponse n'etait pas de l'expliquer, c'etait de la lever.
--
-- LE MODELE Y ETAIT DEJA PRET : CanalNotification portait ses trois valeurs depuis le premier
-- jour, et notifications.alerte est figee a l'emission precisement parce que « le classement
-- d'un evenement peut changer d'avis ». Il ne manquait que la colonne.

-- ========================================================= LE CANAL =============
--
-- ON REMPLACE LA COLONNE PLUTOT QUE D'EN AJOUTER UNE.
--
-- Garder « actif » a cote de « canal » creerait deux sources pour une seule decision, avec la
-- question insoluble de savoir laquelle gagne quand elles se contredisent. Le canal dit tout :
-- « rien » est exactement l'ancien actif = 0.
--
-- DESTRUCTIF, ET SANS CONSEQUENCE ICI : cette table ne porte que des DEROGATIONS, et elle est
-- vide en pratique — la fonction vient d'etre livree, aucun concierge n'a encore regle quoi que
-- ce soit. Meme non vide, la perte serait un retour aux valeurs par defaut, pas une perte de
-- donnee metier.
ALTER TABLE notification_reglages
    DROP COLUMN actif,
    -- VARCHAR et non ENUM, pour la meme raison que partout ailleurs dans ce schema : le
    -- vocabulaire est celui de App\Domain\CanalNotification, et un ALTER sur une table qui
    -- grossit se paie. La valeur inconnue est ignoree a la lecture, jamais interpretee.
    ADD COLUMN canal VARCHAR(12) NOT NULL AFTER role;

-- ================================================== LE MASQUAGE ================
--
-- UNE DATE DE MASQUAGE, ET NON UN DELETE.
--
-- Le geste demande est « supprimer d'un clic », et c'est bien ce que l'utilisateur obtient : la
-- ligne quitte son fil, son compteur, definitivement. Mais elle n'est pas effacee de la base,
-- et la raison est precise.
--
-- LA LIGNE PORTE courriel_le. C'est la seule trace, dans toute l'application, du fait qu'une
-- alerte est PARTIE PAR COURRIEL et quand. Le journal d'intervention garde le fait — « annulee
-- le 5 mars » — mais pas « et nous vous en avons averti par courriel le 5 mars a 9h12 ». Or
-- c'est exactement la phrase qui sert le jour ou un proprietaire affirme n'avoir pas ete
-- prevenu. Un DELETE mettrait cette preuve entre les mains de celui qu'elle contredit.
--
-- POUR L'UTILISATEUR, LA DIFFERENCE EST NULLE : la ligne disparait de son fil et n'y revient
-- pas. Personne ne relit ces lignes masquees dans l'application — aucun ecran ne les montre.
-- Elles n'existent que pour repondre a une question qui se pose ailleurs.
ALTER TABLE notifications
    ADD COLUMN masque_le DATETIME NULL AFTER lu_le;

-- L'index du fil doit ignorer les lignes masquees, sinon chaque lecture les parcourt pour les
-- ecarter ensuite. masque_le en tete : c'est la colonne qui elimine.
ALTER TABLE notifications
    DROP KEY idx_notif_fil,
    ADD KEY idx_notif_fil (destinataire_id, masque_le, lu_le, cree_le);
