But

Permettre de gérer les notifications indépendement par entité
Cette page fait suite à celle-ci qui a été écrite précédemment :GlpiNotifications

Proposition

Notification

2 options :
  • créer un objet par évènement
  • créer un objet par évènement et par destinataire

Ces objets pourront être récursifs, être définis par entité et gérer par un droit spécifique.

Evénements

  • les événements du coeur
  • les événements des plugins (un nouveau hook ?)

Méthode de notification

  • Création d'un objet pour un type de notification
    • envoi d'email
    • lancement d'un programme externe (jabber, sms , etc)

Dans un objet notification, on doit pouvoir préciser quelle méthode de notif on désire

Envoi de notifications

Il faut modifier le processus d'envoi des notifications afin de tenir compte de l'entité, et donc de sélectionner la méthode correspondante.

Table actuelle glpi_mailingsettings

  • type = new, update, followup
  • mailtype = USER_MAILING_TYPE, PROFILE_MAILING_TYPE, GROUP_MAILING_TYPE, DB_NOTIFICATION_MAILING_TYPE
  • items_id = groups_id si GROUP_MAILING_TYPE, *_MAILING si USER_MAILING_TYPE

Proposition de tables

glpi_notificationtemplates

=> droit "config" pour créer les template

  • id : identifiant
  • name : nom
  • language :
  • is_default : template utilisé en cas d'absence de la langue du destinataire
  • subject : contenu au format TXT
  • content_text : contenu au format Text (si absent => html_clean du html)
  • content_html : contenu au format HTML (si absent => texte seul)
  • comment
  • itemtype : item concerné par ce template

Il sera donc nécessaire de fournir un template par défaut pour chaque "eventype" (coeur + plugin)
Le content devra pouvoir contenir
- des balises remplacées par les données de l'objet (ticket, ...)
- des chaines faisant référence au $LANG (principalement pour ceux fournit par le coeur pour ne pas en créer 1 par langue)

Gestion des langues et du is_default

Remi :

  Une proposition qui me semble simple à mettre en oeuvre
  On vire le champ is_default (qui sert visiblement à rien)
  ON ajoute un champ notificationtemplates_id(_translation)
  Règles :
    notificationtemplates_id==0 => template principal (par défaut)
    notificationtemplates_id>=0 => une traduction
  Sur le form de saisi du template
    - si il y a des traductions => plus possible de changer, ça reste
  forcément un "principal" 
  Dropdown de choix d'un template => uniquement les principaux
  Recherche du template pour un événement
  (glpi_notificationtemplates.notificationtemplates_id
    = glpi_notification.notificationtemplates_id
 AND glpi_notificationtemplates.language = user.language)
  OR (glpi_notificationtemplates.id
    = glpi_notification.notificationtemplates_id )
  En résumé..
  1/ évenement
  2/ pour chaque notification
  3/ recherche des destinataires
    => tri par langue
  4/ pour chaque langue
    => recherche du template
    => calcul et envoi

Moyo :

Il y a effectivement 2 choix pour résoudre le soucis :
1 - Ajout d'un champ pour définir le template de référence
2 - Sortie des traductions dans une autre table

Personnellement je préfère la solution 2.
J'ai généralement un peu peur des systèmes de liaison via un champ car ca implique pas mal de contraintes à ajouter dans le code (blocage si principal, association d'un template à un autre que si même type...). 

Table glpi_entitydatas

Ajout des champs suivants :
  • mailing_signature : signature du mail propre à l'entité
  • cartridges_alert_repeat
  • consumables_alert_repeat
  • user_licences_alert

Ajout d'un onglet "Notifications" dans la fiche d'une entité. On ne peut accèder à cet onglet qu'avec le droit "Notifications".

Définition des TAGs à utiliser dans les modèles : NotificationTemplatesTags
Définition des évènements : NotificationEvents

glpi_notifications

(pour éliminer "mail", même si c'est le seul moyen actuellement)

  • name
  • entities_id
  • is_recursive
  • itemtype
  • event = nom du déclencheur (new, update, solved, closed, survey, ...)
  • mode = de notification (mail uniquement pour l'instant)
  • notificationtemplates_id = nom du template
  • comment

glpi_notificationtargets

  • notifications_id
  • type = reprise de l'ancien mailingtype
  • items_id = reprise
  • MoYo : ne peut t'on pas simplifier la gestion ? ca fait beaucoup de données en doublon dans une configuration réelle.
    • Une idée : définir un objet de notification : action / mode / template / content et sortir l'association aux personnes dans une autre table ? voir même mode + template également dans une autre table (pour le moment on a que mail mais bon) ?
  • Remi : Le "template" sera forcément différent en fonction de l'évenement.. et on peut vouloir un mail différent vers les tech et les users... Mais effectivement, si on peut définir plusieurs entrées pour un même event / mode / template ça marche aussi (bon, dans tous les cas, ça va être la merde à éliminer les doublons, pour pas trop spammer...)
    • Moyo : on le fait déjà avec le système actuel. Le seul problème qu'on peut se poser est de trouver un système pour prioriser les association. Dire que tel template passera avant celui là dans le cas ou on en a 2 affectés pour la même personne.
  • Walid : donner le choix à un tech de modifier les options de notifications dans ses prefs utilisateurs. Par exemple, un tech peut définir que certains évènements vont donner lieu à une notification XMPP au lieu de mail (voir même jamais de mail, que du XMPP)

HOOK

  • use_notification => impliquant 3 fonctions (peut-être plus)
    • plugin_foo_getNotificationItemType() : pour affichage de la dropdown avec ceux du coeur (liste de classe)
    • <ItemType>::showNotificationType($event) : dropdown
    • <ItemType>::showNotificationItem($event, $type) : dropdown (si besoin)

Fonctions

  • getNotificationType($event, $entity, $plugin='') => extraction des champs de la table glpi_notifications
  • getNotificationTemplate($event, $language)

Classes