Re: [Dolibarr-dev] module workflow

[Laurent Destailleur (Eldy)]

Le 22/04/2010 00:28, Régis Houssin a écrit :
> 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 ?
>   
Oui en effet, il faut que dolibarr par défaut soit "sans workflow"
automatisé, donc sans création automatique d'entité X quand on créer une
entité Y.
Il ne doit pas y en avoir des masses actuellements. Celle qui existe
sont à virer.

> 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
>> ?
>>     
>>
>>
>> _______________________________________________
>> Dolibarr-dev mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>>     


-- 
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr

Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: address@hidden
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: address@hidden
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net