Re: [Dolibarr-dev] table llx_element_logs

[Laurent Destailleur (eldy)]

Je ne suis pas sur qu'une telle fonctionnalité soit nécessaire dans
dolibarr.

En général la regle du "le dernier qui modifie a raison" est souvent
préféré y compris chez les très gros ERP.
La notion de verrou applicative n'est en place que dans 0.5% des
fonctions métiers en entreprises et est à réserver à de situations qui
peuvent générer des conflits graves.
En effet, cela genere beaucoup plus de pb que d'avantages.

La personne lock et part a la machine a café ou en vacance, il faut du
coup des fonctions de dévérouillage.
Ou encore on verrouille une facture mais sur une fiche il n'y a pas que
la facture il y a les lignes qu'il faut aussi vérrouiller et puis sur un
fiche produit il faut aussi verrouillé la table des prix, tables des
traductions, etc, etc..

Voila pourquoi tres peu de produit implement une telle fonction. Pour
fournir des telles applications dans mon cadre professionnelle, elles
sont aujourd'ui banis des entreprises de plus en plus, y compris dans
des produits comme SAP ou autres projets à fort nb d'utilisateurs alors
autant dire encore plus sur les projet a faible taux d'utilisateur.

La regle du dernier qui a modifié a raison est préférable.
Si un utilisateur modifie à 8h et un autre à 9h on trouve normale de
garde l'info de 9h donc si la situation se pose avec 8h et 8h et 1
secondes, il n'y pas de raison de faire autrement.

Pour moi il ne doit surtout pas y avoir de telles fonctions dans Dolibarr.
C'est le genre d'evol qui transforme Dolibarr en SAP (en encore meme SAP
ne fait plus cela dans la plupart de ces modules).



Le 09/11/2010 13:41, address@hidden a écrit :
> Le 09/11/2010 10:03, Régis Houssin a écrit :
>> je transfert mon message sur la liste pour avoir votre avis:
>>
>>
>> il y a une discussion sur le forum concernant le lock des fiches
>> ouvertes qui éviterait la modification simultanée de celle-ci.
>>
>> au lieu d'ajouter un champ lock dans chaque table, je pensais ajouter
>> une table qui permettrait de stocker l'état actuel (lock/unlock) de la
>> fiche, un peu comme sous joomla.
>>
>> par la même occasion on pourrait en profiter pour utiliser cette table
>> afin de stocker les logs des différentes interventions sur un element,
>> ceci permettrai d'avoir un historique complet des modifications.
>>
>> avec des champs du style:
>>
>> - fk_element = id de l'élément
>> - elementype = type d'élément
>> - datel = date du lock
>> - dateu = date du unlock
>> - lock (ou status) = état de l'element
>> - fk_user = user qui a fait l'action
>> - action = type d'action sur le document
>>
>> on pourrait mettre en option la possibilité d'activer ou pas la fonction
>> log, ce qui permettrai de ne garder que la fonction lock pour ceux qui
>> ne souhaitent pas d'historique (évite la surcharge de la base), dans ce
>> cas là les logs seront effacé dès le unlock de l'élément.
>>
>> qu'en pensez-vous ?
>>
>>
>> Cordialement,
> Très bonne idée de laisser le choix, sinon cette fonctionnalité donnera
> encore beaucoup plus de crédibilité à Dolibarr.
> 
> @+
> Philippe
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/dolibarr-dev