Re: [Dolibarr-dev] module workflow

[Laurent Destailleur (Eldy)]

Tu veux dire qu'on passerait aux trigger l'info "module workflow actif"
et ainsi le trigger du module externe peut décider que si module
workflow actif, il ne fait rien ou faire autrechose ?

Pourquoi pas. Mais l'info est deja passé au trigger externe via $conf
->workflow->enabled
Le trigger externe peut donc dejà décider de ne rien faire si il
considère que le module workflow se substitue à son travail.


Le 22/04/2010 08:18, Régis Houssin a écrit :
> Alors je propose une solution plus souple,
> On continu de créer des triggers comme on le fait actuellement mais en
> ajoutant un paramètre à ceux qui serait susceptible de fonctionner avec le
> module workflow, si le module est activé c'est le trigger "WorkflowManager"
> qui décidera suivant la configuration si il doivent s' exécuter ou pas,
> ainsi nous aurions un fonctionnement statique et un fonctionnement
> dynamique.
>
> Vous en pensez quoi ?
>
>
> Le 22/04/10 00:28, « Régis Houssin » <address@hidden> 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 ?
>>
>> 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
>>     
>   
>
>
> _______________________________________________
> 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