Re: [Dolibarr-dev] table llx_element_logs

[Laurent Destailleur (eldy)]

Si c'est un warning, ca va.
Par contre ca doit etre une option non active par défaut.
De plus il faut définir un délai a partir duquel on considère qu'il n'y
a plus de modif en cours meme si le tag est présent. Du coup, ca rend la
fonction un peu inutile car elle peut dire "encours de modif" alors que
c'est pas le cas et elle peut ne rien dire car le time out est expiré
alors que c'est le cas.

Du coup, c'est une fonction non fiable et qui génere de
l'incompréhension pour l'utilisateur qui croit etre protégé mais ne
l'est pas.

Donc à fournir en option non active par défaut.


Le 11/11/2010 01:52, Régis Houssin a écrit :
> On ne verrouille pas les tables, on stock que l'id de l'élément qui est en 
> train d'être édité, a partir de la si une autre personne veut modifier 
> l'élément où qu'il soit on lui signal que celui ci est en train d'être 
> modifié par quelqu'un d'autre. En ce qui concerne le debloquage on peut, au 
> moment d'une action d'édition, vérifier le temps Max d'un Lock et débloquer 
> si c'est dépassé. Ça évite de faire intervenir un admin pour débloquer.
> 
> Ça évitera pour certain de perdre des modifications bêtement.
> 
> -----------------------------------------
> Régis Houssin
> Tél. +33633020797
> http://www.dolibarr.fr
> http://www.dolibox.fr
> 
> Le 11 nov. 2010 à 01:03, "Laurent Destailleur (eldy)" <address@hidden> a 
> écrit :
> 
>>
>> 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
>>
>> _______________________________________________
>> 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