Re: [Dolibarr-dev] module workflow

[Régis Houssin]

Ok je viens de piger
Par contre on risque d'avoir des doublons si des triggers du système font la
même action que le trigger du workflow

Par exemple je voulais migrer en trigger la création de la commande
lorsqu'une propale est signée, du coup je vais plutot mettre ceci dans le
trigger du workflow ?

Ensuite il va falloir déterminer si un trigger d'un module externe est fait
pour le système ou pour le workflow ?




Le 21/04/10 23:11, « Laurent Destailleur (Eldy) » <address@hidden> a
écrit :

> Le 21/04/2010 22:43, Régis Houssin a écrit :
>>   
>>> Le module workflow est un module qui activé, permet d'offrir
>>> des fonctions de visu ou modif du workflow (donc d'enchainement des
>>> étapes métiers).
>>> Les triggers sont eux des fonctions intrinsèques a dolibarr.
>>> Le workflow devrait fonctionner grace aux triggers et non l'inverse.
>>>     
>> Comme je vois la chose le workflow et les triggers sont liés étroitement,
>> car pour gérer les processus métiers et gérer les enchainements entre les
>> actions et les modules il faut bien réagir en fonction d'une action, et
>> c'est justement les triggers qui permettent ça.
>> Je me disait que le module workflow permettrait de gérer l'activation et la
>> liaison des triggers entre les modules. Par exemple un triggers
>> "PropalWorkflow" pourrait contenir divers mode de réaction en fonction de la
>> configuration du workflow, lors d'une clôture de propal on pourrait
>> paramétrer le workflow pour dire au trigger de créer une commande ou créer
>> un bon d'intervention ou les deux.
> Oui c'est bien pour cela qu'on était fait le triggers.
>>  Ou alors créer toute une panoplie de
>> triggers ayant des fonctions précises et les gérer et les faire réagir avec
>> le workflow. Pour moi les triggers à l'heure actuelle ne sont ni plus ni
>> moins qu'un fonctionnement de workflow qu'on ne peut pas manipuler comme on
>> veut.
>>   
> Je ne comprend pas. Pourquoi dis tu qu'on ne peut pas les manipulé. Ils
> sont justement adaptés au processus que tu décrit.
> Tu ajouter un trigger nommé
> interface_modWorkflow_Manager.class.php
> 
> et a chaque fois qu'une action dolibarr est faite, ce trigger va lire la
> config et fait l'action complémentaire en conséquence.
> Tu fermes une propale et dans ce trigger tu peux créer une facture si
> l'utilisateur a configuré créer facture sur fermeture de propale.
> 
> Un trigger n'est pas un workflow mais un mécanisme technique.
> Un workflow, c'est une configuration.
> 
>>   
>>> Les fonctions workflow seront utiles mais doivent se greffer au dessus du
>>> noyau et non en dessous.
>>> Pourquoi as-tu besoin de faire ces modifs pour déterminer les processus
>>> métiers.
>>> Ceci peut se faire en créant un simple trigger "workflow". Ce dernier irait
>>> lire une config
>>> préétablie et ferait les actions en conséquences ?
>>>     
>> On ne peut pas laisser à la fois les triggers comme c'était et ajouter un
>> fonctionnement de workflow par dessus, c'est ingérable.
> Pourquoi, cela fait exactement ce que tu décrits ?
>>  Le workflow
>> permettrai justement de mieux gérer les triggers. Du moins c'est mon avis.
>> 
>> Le souci actuel c'est qu'une fonction appelle les triggers et qu'ils sont
>> exécutés sans contrôle,
> Pourquoi sans controle ?
> C'est a ton trigger, propre au module workflow de gérer le controle.
> Eventuellement ton trigger peut provoquer la désactivation de triggers
> d'autre modules. Mais tu as un controle total. A toit de mettre ce
> controle dans ton module.
>>  je veux juste ajouter une couche intermédiaire, le
>> workflow, qui permettra de gérer les triggers en fonction du processus
>> métier voulu.
>>   
> Bah oui, tu l'as. Il te suffit de la mettre dans le fichier
> interface_modWorkflow_Manager.class.php
> 
> C'est dans le code du trigger que tu dois gérer ton workflow. Non l'inverse.
> Si j'ajoute un module Y pour créer une trace dans une base de donnée, je
> vais mettre un trigger.
> Si tu veux un module Wrokflow qui fait des choses en plus selon une
> certaine config, et le module Y n'a ps a etre géné par le module
> Workflow ni avoir d'imapct dessus. Et l'inverse et également vrai.
> Je pige donc toujours pas ce que tu veux faire. Le trigger permet
> d'ajouter le comportement complémentaire entre entité que tu désires.
> Tu ne pourras jamais avoir de controle sur les autres triggers car:
> 1) ce n'est pas possible car tu ne peux pas savoir ce que font les
> triggers développés par d'autres
> 2) ce n'est pas souhaitable car cela casse complètement la modularité et
> l'indépendance des modules.
> 
> Tu pourrais y faire ce que tu veux en fonction d'une config de
> l'utilisateur ?
> Utilisateur 1 veut que validation propal crée commande et que création
> contrat crée facture, il configure le module workflow (tables dédiées au
> module) et ce trigger le fait.
> Si l'utilisateur 2 veut le contraire, il configure le module workflow et
> le trigger le fera aussi vu que ce trigger se base sur la config pour
> savoir quoi faire.
> 
> 
> Quand les triggers ont été mis en place, c'est justement dans l'arriere
> pensée de pouvoir modifier ce workflow et c'est aussi pour cela que le
> workflow n'est pas automatisé actuellement dans le code mais est ouvert
> et manuel.
> 
> Pourquoi ne fais tu pas ce que tu évoques dans un trigger
> interface_modWorkflow_Manager.class.php
> ?

smime.p7s
Description: S/MIME cryptographic signature