Re: [Dolibarr-dev] module workflow

[Laurent Destailleur (Eldy)]

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
?


>  
>   
>>
>>
>> Le 21/04/2010 18:37, Régis Houssin a écrit :
>>     
>>> J¹ai ajouté un module ³workflow² (actif par défaut) et modifié l¹appel
>>> des triggers dans les classes.
>>> L¹appel sera dorénavant : call_workflow() au lieu de run_triggers()
>>>
>>> Ceci permettra de déterminer le workflow de l¹entreprise et/ou de
>>> certaines tâches
>>> Ensuite le workflow fera appel aux triggers pour les exécuter.
>>>
>>> désolé du dérangement pour ceux qui développent des modules externes
>>> mais ca devient vraiment indispensable de pouvoir déterminer des
>>> processus métiers.
>>>
>>>
>>> -- 
>>> Régis Houssin
>>> ------------------------------------------------------
>>> *Cap-Networks
>>> *30, Quai de Verdun
>>> 71700 Tournus
>>> Tél. +33 6 33 02 07 97
>>> Web: http://www.cap-networks.com
>>> Email: address@hidden
>>>
>>> *Développeur Dolibarr : address@hidden
>>> *Portail francophone : *www.dolibarr.fr
>>> *Offres SaaS de Dolibarr : *www.dolibox.fr
>>> *Development platform : *www.dolibarr.pro
>>> ------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> 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