Event management

Gestion d'événement

A étudier : notification sur événements ?

- Système de notifications et de gestion d'événements global.
- Événements enregistrés dans une table
- Lien des événements avec les modes de notifications et les utilisateurs rattachés
- Événements standards simples :
- Ajout / Suppression / Mise à jour / Purge / Mise à jour du champ X
- Événements particuliers à insérer dans GLPI via un sendEvent() par exemple
- Gestion des événements des plugins
- Système d'événements pas inclus que pour notifications : 
- peut permettre d'effectuer des actions spécifiques (changement status...)
- Voir si des hooks / actions manquent :
- install / desinstall logiciel
- connexion / déconnexion
- Critères :
- Ajouter la notion d'unité de mesure lorsque le typage est numérique ? (champ optionnel) (ex : $criterias['name']['unit'] = 'mo';)

Table d'enregistrement des évènements pour la notification

Cette table sert à

CREATE TABLE `glpi_eventnotifications` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `itemtype` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
  `items_id` int(11) NOT NULL DEFAULT '0',
  `users_id` int(11) NOT NULL DEFAULT '0',
  `date` datetime DEFAULT NULL,
  `action` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
  `field_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `old_value` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `new_value` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
   PRIMARY KEY ( `id` )
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
  • itemtype : type d'item pour laquelle il y a eu une action
  • items_id : id de l'objet (dans le cas d'un ajout, modification et de suppression, et donc 0 pour la purge)
  • users_id : id de l'utilisateur qui a fait l'action
  • date : date de l'action
  • action : le type d'action au choix : add, delete, purge et update
  • field_name: nom du champs de la DB qui a été modifiée (uniquement pour l'action update). Ce champs peut etre vide pour l'update et alors on aura juste une notification de mise a jour de l'élément
  • old_value : l'ancienne valeur
  • new_value : nouvelle valeur

Ces evènements seront remplis à chaque action du CommonDBTM : add(), update(), delete() et appellera une fonction d'ajout d'évènement suivant la configuration et donc qu'est ce qui va être notifié ici

MoYo : quel est l'utilité de chaque champ ? Dans les événements prévus comment se remplira cette table ?
David : j'ai mis à jour
Moyo : je ne saisi pas trop pourquoi stocker ça alors que la notif pourrais être expédiée à chaque événement. C'est comme ça que j'avais compris ce chantier. Quid de la partie action sur événements ? Je pense que ce chantier est plus complexe que cela.
David : j'ai peur des soucis de perf si on doit envoyer une alerte a 5 personnes pour chacun des 20 champs modifié sur un ordinateur par exemple, ca fait 50 mails qui partents, alors qu'en stockant en base, on envoi en une fois pour chaque personne). Peut être que je me trompe sur les soucis de perf

Modification des notifications

Il faut pouvoir paramétrer dans une table des champs déclencheurs pour une notification. Par exemple, une notification sur la modification d'une catégorie de ticket. Le mieux est de gérer celà avec les getSearchOptions de chaque itemtype.

CREATE TABLE `glpi_notificationevents` (
  `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
  `itemtype` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
  `field` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
  `event` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `notifications_id` int(11) NOT NULL DEFAULT '0',
   PRIMARY KEY ( `id` )
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Exemple :
itemtype = Ticket
field = 12 // numéro du champ du getSearchOptions de Ticket
event = update // possibilités: update, add, delete, purge

Dans cet exemple, on défini une notification sur un UPDATE du champ "statut" des tickets.
Il faudrait la possibilité d'avoir 0 en event pour le cas ou on gère l'objet en entier : si on veut une notification sur l'ajout ou la suppression d'un ordinateur par exemple.

Cron

Le cron va permettre d'envoyer les notifications enregistrées dans glpi_eventnotifications et suppression de ces lignes une fois les notifications parties.

Il sera configurable :

1 minues / 5 minutes ... / toutes les heures / tous les jours

Mail

Le mail pourrait avoir cette forme :

Les éléments suivants ont été ajoutés : 

* Ordinateur <a href="http://127.0.0.1/glpi/front/computer.form.php?id=165">nom de l'ordi</a> le 27 Mai 2010 à 15h30 par David Durieux
* Ordinateur <a href="http://127.0.0.1/glpi/front/computer.form.php?id=166">nom de l'ordi</a> le 27 Mai 2010 à 16h06 par David Durieux

Les éléments suivants ont été supprimés

* Ordinateur "nom de l'ordi", numéro de série le 27 Mai 2010 à 15h55 par David Durieux

Les éléments suivant ont été modifiés : 

* Ordinateur <a href="http://127.0.0.1/glpi/front/computer.form.php?id=165">nom de l'ordi</a> le 27 Mai 2010 à 16h02 par synchro OCS
  * statut : en stock => en service
  * Utilisateur : => ddurieux