Triggers-actions

= Ajouter son code sur un événement Dolibarr =

Pour permettre de déclencher du code personnalisé en réaction à un évènement Dolibarr (création/modification/suppression d'une société/facture/produit/utilisateur ou autre), Dolibarr propose un mécanisme de triggers métiers. Ce mécanisme vous permet de personnaliser un workflow afin que les évènements de gestion Dolibarr soient répercutés dans une autre application par exemple. Rien n'empêche également de l'utiliser pour modifier le comportement de Dolibarr même: par exemple, pour que la validation d'une facture provoque la création d'un contrat automatiquement.

Donc, pour ajouter son propre code qui sera déclenché par trigger, la procédure est la suivante:

1) Copier le fichier htdocs/core/triggers/interface_90_all_Demo.class.php-NORUN sous le nom: ou bien où Xxx est une chaine de votre choix commençant par une majuscule, 99 est le numéro de priorité du trigger (01 étant le plus prioritaire), MonModule est le nom du module si votre trigger ne doit être activé que si le module MonModule est actif. Si on désire que le trigger soit toujours actif, on mettra all à la place de modMonModule. Il faut laisser ce nouveau fichier dans le même répertoire. Rem: Les valeurs utilisable pour modMonModule sont visibles dans le répertoire htdocs/core/modules. ATTENTION: Tous ces paramètres sont nécessaires pour que le trigger soit détecté! Ex: si vous oubliez le numéro de priorité, le module ne sera pas detecté!
 * interface_99_all_Xxx.class.php
 * interface_99_modMonModule_Xxx.class.php

Par exemple, on pourra nommer notre nouveau trigger: htdocs/core/triggers/interface_99_modFacture_Monworkflow.class.php

En créant un fichier nommé comme dans cet exemple, notre nouveau trigger sera déclenché à chaque évènement métier Dolibarr et à condition que le module Facture soit actif.

Note: Avec Dolibarr 3.2+, il est aussi possible de placer les fichiers triggers dans un sous-dossier de module. Ex: si le module réside dans htdocs/mymodule/, alors il est possible de placer les triggers dans htdocs/mymodule/core/triggers/. Mais dans ce cas, le trigger ne sera trouvé que si vous le déclarer dans le fichier descripteur de votre module. Pour cela, ajouter ajouter triggers->1 dans le tableau module_parts (ex: /monmodule/core/modules/modMonModule.class.php): Puis désactiver et réactiver le module. Ceci aura pour effet d'ajouter une ligne dans la Table llx_const pour indiquer à Dolibarr qu'il faut recherch un trigger dans le répertoire de votre module htdocs/monmodule/core/triggers.

2) Editer ce fichier interface_99_modMonModule_Monworkflow.class.php afin de renommer la classe InterfaceDemo par InterfaceMonworkflow

Ensuite, accéder à la page Accueil-> Infos Systèmes -> Dolibarr -> Triggers. Votre fichier trigger doit apparaitre dans la liste sans erreur indiquant que les opérations précédentes ont été réalisées avec succès.

3) Revenez maintenant à l'édition du fichier trigger afin d'ajouter votre code dans la fonction run_trigger. Cette fonction est appelée à chaque évènement Dolibarr. Placer votre code en fonction du ou des évènements sur lesquels vous voulez réagir, chaque évènement étant identifié par un code (voir chapitres suivant pour la liste des codes), on peut réagir ou non à un évènement donnée par un test sur la variable $action:

Vous pouvez faire ce que vous voulez dans cette portion de code du moment que la fonction run_trigger renvoi un code retour sur le principe suivant:

<0 si ko, 0 si aucune action faite, >0 si ok

Vous pouvez de plus dans cette fonction utiliser les objets suivant:
 * $object est l'objet sur lequel porte l'action (voir chapitre suivant)
 * $user est l'objet de l'utilisateur Dolibarr qui réalise l'action
 * $langs est l'objet qui contient la langue de l'utilisateur Dolibarr
 * $conf est l'objet qui contient toute la configuration de Dolibarr.

4) Une fois le code réalisé, il n'y a plus qu'à tester, en provoquant l'évènement déclencheur dans Dolibarr. Attention, l'appel au run_trigger et encapsuler dans un transaction. Si votre trigger renvoie un code ko, la fonction appelante peut annuler la transaction (ceci dépend de la fonction appelante). Ajouter des traces dans un fichier dans la fonction run_trigger afin de vous assurer que le code s'exécute bien. Vous pouvez pour cela si vous le désirer, utiliser la fonction dol_syslog("mon texte de trace", LOG_DEBUG);

= Liste des évènements gérés = La liste de tous les évênements qui provoque un déclenchement de trigger sont disponibles dans la table Table llx c action trigger. Voici un vue rapide des evênements identifiés par la valeur suivante au code $action avec le type de l'objet reçu dans $object:

Liste non exhaustive.

= Gérer de nouveau évènements =

Pour gérer d'autre évènements que ceux ci-dessus, il faut modifier le code Dolibarr pour y ajouter la séquence suivante dans les méthodes métiers des classes utilisées pour gérer les évenements:

Ici, $this doit être l'objet de la classe métier qui contient toutes les informations à passer au trigger. Remplacer, de plus, le 'XXXXX_YYYYY' par un code évènement non déjà utilisé. Il sera alors possible d'ajouter dans la méthode run_trigger, un if qui permet de gérer ce code. La méthode run_trigger serait alors de la forme :

= Conclusion = Vous pouvez donc en quelques minutes, ajouter une interface Dolibarr vers exterieur sans risque puisqu'on ne touche pas au code Dolibarr, on s'est contenté de placer un nouveau fichier trigger dans le répertoire des triggers. Si cette interface peut être utile à d'autre, n'hésitez pas à la packager en tgz (voir la page Développement_module) et de la soumettre dans l'espace des téléchargement-contributions sur le site de Dolibarr.

= Voir aussi =
 * Système de Hooks
 * Interfaces Dolibarr vers exterieur
 * Interfaces Exterieur vers Dolibarr