dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] module workflow


From: Régis Houssin
Subject: Re: [Dolibarr-dev] module workflow
Date: Wed, 21 Apr 2010 22:43:10 +0200
User-agent: Microsoft-Entourage/12.24.0.100205

> 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. 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.

> 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. 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, je veux juste ajouter une couche intermédiaire, le
workflow, qui permettra de gérer les triggers en fonction du processus
métier voulu.

 
> 
> 
> 
> 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
>>   
> 

-- 
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
------------------------------------------------------

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]