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) » <[email protected]> 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 >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> -- Eldy (Laurent Destailleur). --------------------------------------------------------------- EMail: [email protected] Web: http://www.destailleur.fr Dolibarr (Project leader): http://www.dolibarr.org To make a donation for Dolibarr project via Paypal: [email protected] AWStats (Author) : http://awstats.sourceforge.net To make a donation for AWStats project via Paypal: [email protected] AWBot (Author) : http://awbot.sourceforge.net CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net _______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
