Le respect du **planning** d'affichage d'une alerte puisée en base de données...
Le respect du **planning** d'affichage d'une alerte puisée en base de données devient incontournable (cf. [README.md](README.md#ruptures-de-compatibilité).
Changes for CHANGELOG.md: 4 added lines, 0 removed lines.
Original line number
Diff line number
Diff line
CHANGELOG
=========
4.0.0
-----
- Le respect du **planning** d'affichage d'une alerte puisée en base de données devient incontournable (cf. [README.md](README.md#ruptures-de-compatibilité).
3.2.0
-----
- FlashMessengerContainer : possibilité de recevoir une liste de messages pour une même sévérité.
Changes for README.md: 52 added lines, 21 removed lines.
Original line number
Diff line number
Diff line
@@ -30,9 +30,6 @@ Une alerte a les caractéristiques principales suivantes :
-`severity` : Sévérité de l'alerte ({@see Alerte::SEVERITY_INFO} par défaut)
-`duration` : Durée d'apparition de l'alerte avant sa disparition, en ms (0 = durée infinie), SI SUPPORTÉE par le mode d'affichage choisi ultérieurement
Une alerte stockée en bdd peut avoir une période d'affichage (appelée de façon un peu ambitieuse "planning"), càd une date de début
et une date de fin d'affichage, qui pourra être respectée ou non lors de la demande d'affichage.
Le module fournit l'aide de vue `alertes()` (cf. `UnicaenAlerte\View\Helper\AlerteViewHelper`).
Remarques :
@@ -40,6 +37,17 @@ Remarques :
- La prise en compte de la période d'affichage n'est possible que pour les alertes puisées en bdd.
### Alertes en base de données
#### Planning
Une alerte stockée en bdd peut avoir un **planning** d'affichage (table `unicaen_alerte_alerte_planning`),
càd une ou plusieurs périodes précises (date de début, date de fin) pendant lesquelles doit s'afficher l'alerte.
Si aucun planning n'est spécifié, l'alerte sera prise en compte systématiquement.
// Affichage d'une alerte puisée en bdd identifiée par son code, sous forme d'un Toast Bootstrap, à condition que son planning d'affichage inclue la date du jour :