Admin: ajout des encarts d'alerte dans l'admin pour permettre au métier de les modifier

[laurinehu]

🤔 Quoi ?

> Indiquez le problème que nous sommes en train de résoudre. Renseignez l'url vers la carte notion si besoin.

🍰 Comment ?

Ajout de 4 propriétés aux TBs:

• com_alert : booléen indiquant si l'alerte doit être activée (une autre option était de ne mettre qu'un champs de texte, mais du coup si on veut désactiver momentanément une alerte, on perd le texte, tandis qu'avec cette option, on peut laisser la config de l'encart mais le désactiver en un clic)
• com_alert_descr : la description / accroche de l'encart
• com_alert_text : le texte
• com_alert_link : le lien qui renvoit vers l'enquête tally (enfait idéalement, il faudrait que ce soit aussi une option, je viens d'y penser en écrivant, mais je laisse pour ce premier test qu'on va discuter ensemble)

Je n'ai pas testé pour le moment. Je laisse en draft. mais preneuse d'en parler avec @rsebille ASAP :)

Notamment j'ai l'intuition qu'utiliser 4 propriétés pour une action n'est pas forcément une bonne pratique.
Preneuse si tu connais une alternative propre

[laurinehu]

Pour le moment j'ai mis par défaut les données qu'on affichait (avant cette PR) pour quasi tous les TBs. C'est pour éviter (quand on passera la PR) de devoir aller dans l'admin mettre cette data pour tous les TBs. On aura juste à faire la modif pour le 408 qui faisait exception. Passée la date du 20/10, on pourra retirer ces default (ou trouver un moyen -que je ne connais pas- de les garder dans l'admin sans les garder en default dans le code).

[rsebille]

Comme je disais dans mon (rapide) message, c'est une manière de faire qui fonctionne mais ce n'est pas l'idéal en terme de modélisation.

En règle générale on essaie de séparer dans des modèles différents afin de découpler les fonctionnalités et responsabilités pour ensuite lier les deux avec des champs de liaisons relationnels.
Ça permet aussi de ne pas avoir des classes de modèle ou de formulaire avec des centaines de lignes car faut gérer tout au même endroit, avec les problèmes que cela engendre quand on commence à ajouter de la logique métier.
Ça ne nous concerne pas vraiment au vu de notre quantité de donnée mais il y a aussi des implications au niveau de la performance au jour le jour ou lors de la migration de donnée mais aussi pour réduire la surface lors du lock de table quand on ajoute un nouveau champ.

Dans le cas présent j'identifie déjà ces limitations :

• Impossible d'avoir plus de 1 bannière associé à 1 tableau de bord, ce qui en soit pourrais suffire mais va très vite rentrer en conflit avec d'autre choses :)
• Si on veux mettre un encart sur plus de 1 tableau de bord alors faut dupliquer l'encart dans tous, c'est pas super pratique
• On veux pouvoir, a minima, dépublier un tableau de bord automatiquement afin de ne pas envoyer l'utilisateur vers un lien "mort" mais aussi éventuellement la publication afin de ne pas avoir à être sur le pont au bon moment
• Si jamais on voulais un encart par défaut on devrais de nouveau le faire dans le code, et si jamais on se retrouve dans la situation où on veux en avoir plusieurs alors on retombe dans le cas actuel où faut faire du code.

[rsebille]

Je met un peu tout en vrac car des remarques sont communes :

• default doit être une valeur qui fonctionne par défaut et donc a priori générique, mais là tu as repris les valeurs existantes et donc spécifique à 1 cas
• Vu qu'on est sous PostgreSQL tu n'as pas besoin (c'est même mieux) de passer de max_length, ça évite de devoir se poser la question du nombre maximum ou d'avoir un problème de taille dans le futur ;) : https://docs.djangoproject.com/en/5.0/ref/models/fields/#django.db.models.CharField.max_length
• Django propose un URLField, c'est toujours mieux d'utiliser le champ le plus proche de la sémantique voulue car derrière ça permet au formulaire d'utiliser le bon type d'input et les bon validateurs de données : https://docs.djangoproject.com/en/5.0/ref/models/fields/#urlfield