Le 04/06/2011 17:23, Régis Houssin a écrit :
Bonjour,
je regrette le fusionnement des actions et de l'agenda,
Euhh, c'est la meme chose (action = evennement de l'agenda)
nous sommes obligés d'activer le module agenda pour faire fonctionner le
suivi d'action (envoi par mail d'un document, etc...)
Oui, normal, car le module agenda a pour but d'avoir un suivi des
evennement qu'ils soient auto ou manuel.
On y configure les actions qu'on veut tracer dans l'agenda.
Il n'a pas pour but de suivre le cycle de vie d'un document.
Pour cela, (suivi du cycle de vie d'un facture par exemple), le tracage
"en table de log" doit etre utilisé. Cela n'est implémenté que dans les
commandes fournisseurs pour l'instant, dans l'onglet "suivi" mais cela
pourrait etre reproduit pour tout autre objet.
ceci devrait être deux modules, un module action et un module agenda,
surtout si on veut les actions de documents et utiliser un agenda externe.
C'est bien déja le cas. C'est juste que le tracage du cycle de vie dans
le module propre à l'objet n'est pas implémenté ailleurs que pour les
factures fournisseur mais il pourrait l'etre.
je propose de remettre par défaut l'affichage des actions sur les
documents, que ce ne soit plus lié au module agenda.
Non, l'injection auto des actions en agenda est le propre meme du module
agenda (qui a 2 fonctions, saisir des evennement manuels et saisir des
evennement auto dans un calendrier). D'ou la séparation dans la bascule
dans l'onglet agenda, car c'est une fonction propre à ce module.
Toutefois, avoir un suivi du cycle de vie qui lui n'est pas débrayable
ni configurable mais systématique et contiendrait beaucoup plus de chose
peut etre aussi utile, mais dans ce cas voir pour implémenter selon le
principe de ce qui a été fait pour les commandes fournisseurs.
La table de log des commandes fournisseurs pourrait toutefois etre
rendus générique à tout objet. Et les evennement tracés le serait par un
trigger
interface_all_Logevents.class.php (donc tjs actifs)
qui differe du trigger de l'agenda qui lui est propre à l'agenda et a sa
config. La fonction de vouloir tracer dans son calendrier des RDV que ce
soit celui de dolibarr ou que ce soit un calendrier externe est un
besoin tres particulier qu'il ne faut pas généraliser ni activer par défaut.
Le trigger actuel "interface_all_Logevents.class.php" devrait etre
renommé interface_all_SecurityEvents.class.php car il est dédié
uniquement aux audits sécurité.
de plus il y a des incohérences et des limitations dans le
fonctionnement, la table llx_action_def contient des codes de
notifications !
Le module notification est un module a part qui se base sur les
triggers. Il est en effet proche du module agenda dans le sens ou il est
transverse mais la liste des actions gérées est plus restreinte.
de plus je trouve que cette table fait double emploi avec les constantes
des actions, exemple :
dans table llx_action_def on a
NOTIFY_VAL_FAC = validation facture client
constante action agenda pour les factures on a :
MAIN_AGENDA_ACTIONAUTO_BILL_VALIDATE = validation facture client
même source au bout du compte !
Ce sont 2 modules différents et ne gere pas les meme actions. Le module
notification en gere moins pour l'instant mais a terme la liste pourrait
en effet etre commune. Avec les modifs que tu as faite, le mal est en
partie résolu pour ce point. Toutefois comme ce sont 2 modules
différent, le doublons de traduction peut etre conservé, meme si
l'action est bien la meme.
je propose de renommer la table llx_action_def en llx_c_actions_type
afin d'y stocker tout les types d'actions possible, ainsi nous pourrons
les utiliser pour l'agenda, pour les notifications voir pour le workflow.
ainsi nous pourrons aussi ajouter des actions d'agenda sans toucher au
code (module externe)
J'attends vos retours...
Cordialement,
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://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]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
