fix: when create invoices from orders list, title and subtotal attribute is now copied

[FHenry]

With the mass action "Create Invoice from Orders" on orders list the attributes of title and sub total ("show unite price","show sub total",...) are not copies on invoices lines

there was missing code "setExtraParameters" in this case, the "setExtraParameters" was correctly implemented in create invoice from order card

[hregis]

@FHenry il serait peut être moins gourmand en temps de rajouter un paramètre "extraparams" à "addline()" que de refaire un fetch de la ligne ?
et même de revoir la fonction "addline()" car à force nous allons avoir autant de paramètres que de champs !
ce qui n'a aucun sens !

[hregis]

@FHenry @eldy pourquoi ne pas utiliser de suite la classe dédiée aux lignes ?

[FHenry]

@hregis j'avoue que je découvre l'implémentation, même si ça a été dev par un "Scopen", j'ai pas mis mon nez dedans avant maintenant... et je suis un peu surpris des choix qui ont été fait...

[FHenry]

et même de revoir la fonction "addline()" car à force nous allons avoir autant de paramètres que de champs !
ce qui n'a aucun sens !

Je suis d'accords, je ne voulais pas casser la signature de la méthode en 22.0.
J'imagine que c'était l'objectif de passer par extraparams plutôt que par des attributs en plus sur les objets lignes

[hregis]

@FHenry en fait je me fiche que soit stocké dans extraparams, le truc c'est qu'il faudrait éviter de refaire un fetch pour avoir la valeur d'un champ... quand je regarde, parfois, le "dolibarr.log" je me dis qu'il y a une tonne de requêtes sql qui pourraient êtres évitées ! 😄

[hregis]

@FHenry @eldy alors soit on optimise, soit on fait comme le autres, on intègre un cache Memcache et/ou un cache Redis

[FHenry]

J'aurais bien évité le fetch (dans le cas unitaire, pas de "re-fetch" de la ligne) car le $object->lines[] est peuplé avec la ligne nouvellement créée.
Ici $object->lines[] n'est pas peuplé parce que context='createfromclone' .
Pas moyen de récupérer l'instance de la ligne créée par addline autrement que par un fetch

[hregis]

@FHenry @eldy c'est ce que j'ai fait avec Multicompany et ça optimise autant que le module memcache de Laurent...
il faut mettre en cache les dictionnaires dans un premier temps
et faire en sorte que le cache soit modifié ou supprimé dès qu'il y a une modification
ça va accélérer sans nul doute !

[hregis]

J'aurais bien évité le fetch (dans le cas unitaire, pas de "re-fetch" de la ligne) car le $object->lines[] est peuplé avec la ligne nouvellement créée. Ici $object->lines[] n'est pas peuplé parce que context='createfromclone' . Pas moyen de récupérer l'instance de la ligne créée par addline autrement que par un fetch

@FHenry oui je te comprends bien, le soucis c'est que le champ "extraparams" n'est pas dans les paramètres de la fonction...

c'est pour ça qu'il faudrait ne plus passer par des fonctions intermédiaires, mais directement par la classe qui gère les lignes ! sinon on ne s'en sortira pas !

[hregis]

@FHenry ma réflexion sur le cache est pour le "fetch"
mettre en cache jusqu'à ce que la donnée soit modifiée serait à mon sens une façon d'accélérer les affichages (listes et cards... et autres)

[hregis]

@FHenry @eldy après le cache peut être optimisé avec le type de l'élément et son ID, voir même sur des requêtes spécifiques, il suffit juste de donner une clé à ce qu'on met dans le cache.
ensuite si un produit, un tiers ou autres est modifié ont dit au cache que cet ID est modifié...

[hregis]

@eldy on n'arrête pas de me dire qu'il faudrait intégrer Multicompany à Dolibarr... et si on intégrait Memcache et/ou Redis hahaha 😄

[hregis]

@FHenry @eldy à mon avis ça pourrait aussi accélérer l'affichage des listes quand il y a énormément de lignes !

[hregis]

@FHenry @eldy j'espère ne pas parler dans le vide ! 😯