Notifications
Une notification prévient quelqu'un qu'un événement s'est produit : une période clôturée, une tâche de nuit en échec, une planification manquée. Les règles décident quand ; les canaux décident comment — la cloche de l'application, un e-mail, ou un appel à un connecteur.
Vue d'ensemble
Ce que voient les utilisateurs
- La cloche de l'en-tête affiche le nombre de notifications non lues, mis à jour en temps réel. Son menu liste les six dernières ; Tout marquer comme lu et Tout voir sont en bas. Un clic sur une notification la marque comme lue et ouvre son lien.
- La page Notifications (depuis Tout voir) les liste avec les onglets Toutes / Non lues et Tout marquer comme lu.
Chaque utilisateur ne voit que ses propres notifications.
Le compte e-mail
Les e-mails passent par le serveur SMTP défini dans Liberty Next → Administrer → App → Notifications (email) :
| Champ | Défaut | Remarques |
|---|---|---|
| Notifications enabled | activé | Désactivé : aucune règle ne se déclenche. |
| SMTP host, Port | —, 587 | Sans hôte, seule la cloche fonctionne. |
| Encryption | STARTTLS | STARTTLS (usually port 587), SSL / implicit TLS (usually port 465) ou None. Changer d'option règle le port habituel. |
| Timeout (s) | 20 | |
| User, Password | — | Le mot de passe est chiffré avec la clé maître de l'installation. |
| From address | l'utilisateur | Reprend le nom d'utilisateur s'il est vide. |
| Keep read notifications (days, 0 = forever) | 90 | Les notifications lues plus anciennes sont purgées, au démarrage puis toutes les six heures. Les notifications non lues sont conservées. |
Les e-mails sont en texte brut : l'objet, le corps, puis le lien de la règle.
Règles
Les règles se modifient dans Liberty Next → Construire → Notifications et s'enregistrent dans notifications.toml — une modification s'applique sans redémarrage. Send a test envoie la règle en cours de modification, même non enregistrée, avec des valeurs d'exemple à ses destinataires.
Déclencheurs
| Déclencheur | Se déclenche quand | Réglages |
|---|---|---|
| A screen event | Une ligne est créée, modifiée ou supprimée par un écran. | App, Screen, Events (insert / update / delete) et, au besoin, Only when the written row has : des conditions champ = valeur, toutes requises (STATUS = closed). |
| A job event | Une exécution Nomaflow se termine. | Jobs — plusieurs choisies dans une même liste, vide = toutes les tâches — et Events : failure, succeeded, canceled, missed (une planification qui ne s'est pas exécutée — voir Planifications), long_run avec un seuil en minutes, late (aucune exécution réussie à l'échéance Doit avoir réussi avant de la tâche). |
| A screen action | Une action d'écran de type send_notification s'exécute (un bouton ou une étape d'une chaîne d'actions). | Rien de plus : l'action d'écran nomme la règle et transmet les valeurs de la ligne. |
long_run se vérifie à la fin de l'exécution : il signale une exécution qui a duré au moins le seuil, pas une exécution encore en cours.
Canaux
| Canal | Délivre |
|---|---|
portal | Une notification dans la cloche de chaque utilisateur destinataire. |
email | Un e-mail à chaque destinataire qui a une adresse. |
action | Lance une requête (connecteur SQL) ou appelle un endpoint (connecteur API) avec les valeurs du message — pour publier dans Teams ou sur un webhook, ou écrire dans une table de journal. Ses paramètres sont les valeurs de l'événement, plus SUBJECT, BODY et RULE. |
Un canal en échec est journalisé et n'arrête pas les autres. L'envoi se fait en arrière-plan : un enregistrement ou une tâche n'attend jamais le serveur de messagerie.
Destinataires
| Forme | Signifie |
|---|---|
user:alice | Cet utilisateur. |
role:controllers | Chaque utilisateur actif titulaire du rôle. |
email:finance@example.com | Une adresse — e-mail uniquement. |
Dans l'éditeur, choisir les utilisateurs et les rôles dans la liste, ou saisir une adresse. Une entrée sans préfixe qui contient @ est traitée comme une adresse ; toute autre est ignorée et consignée dans le journal.
Variables
L'objet, le corps et le lien acceptent des variables {NOM}, en majuscules ou en minuscules :
| Déclencheur | Variables |
|---|---|
| Événement d'écran | Chaque colonne de la ligne écrite, plus USER, APP, SCREEN, EVENT. |
| Événement de tâche | JOB, RUN_ID, STATE, ERROR, DURATION_MINUTES, ROWS, et EXPECTED_AT pour une planification manquée ou une échéance. |
| Action d'écran | Les valeurs transmises par l'action, plus USER. |
Une variable inconnue est laissée telle quelle. Dans l'éditeur, le bouton à côté de l'objet, du corps et du lien liste les variables du déclencheur et insère celle choisie à l'emplacement du curseur ; le même bouton figure à côté de l'objet et du corps d'une étape notify.
En TOML
[notifications.period_closed]
label = "Période clôturée"
trigger = { kind = "screen", app = "sales", screen = "period_status", events = ["update"], when = [{ field = "STATUS", value = "closed" }] }
channels = ["portal", "email"]
recipients = ["role:controllers", "email:finance@example.com"]
subject = "Période {PERIOD} clôturée par {USER}"
body = "Société {COMPANY} : la période passe en lecture seule."
link = "/screen/sales/period_status"
[notifications.job_failed]
trigger = { kind = "job", events = ["failure", "missed"] }
channels = ["email"]
recipients = ["role:ops"]
subject = "{JOB} : {STATE}"
body = "{ERROR}"
Depuis une étape de tâche
Une tâche peut aussi envoyer elle-même un message, sous forme d'étape, avec en pièces jointes les fichiers qu'elle a produits — une synthèse planifiée. Voir Étapes → Notification.
Les alertes propres à une tâche
Une tâche peut aussi prévenir en cas d'échec sans règle, depuis le bloc Alertes de l'éditeur de tâche :
[jobs.alerts]
on_failure = true
recipients = ["role:ops", "user:alice"]
En cas d'échec, chaque destinataire reçoit une notification Job <id> failed avec l'erreur, dans la cloche et par e-mail. Avec Avertir si une exécution dépasse (minutes) (on_long_run_minutes), une exécution qui dure au moins ce temps envoie en plus Job <id> ran N min (threshold T), qu'elle ait échoué ou non. Écrire les destinataires sous la forme user:, role: ou email: — une entrée sans préfixe est prise pour une adresse e-mail.
Conseils
- Commencer par une règle :
failureetmissedsur toutes les tâches, vers le rôle d'exploitation. - Préférer les rôles aux utilisateurs nommés : la règle suit les changements d'équipe.
- Utiliser Send a test après avoir modifié le compte SMTP.
- Réserver la cloche à ce qui demande une action ; envoyer le reste par e-mail à une boîte partagée.