Bonsoir
La remarque d’Alexandre se tient. Pourquoi migrer sur les nouvelles versions ? Besoin d’une fonctionnalité précise ?
Quand vous parler de service informatique dédié, nombreux sont les intégrateurs (dont je fais partie) sur le forum a proposer des accompagnements. Cela a un coût c’est certain mais a quel votre coût horaire lors de vos heures de recherche sur le forum ?
A votre disposition en tout cas…
@+
1 « J'aime »
Bonsoir,
@Aspangaro,
Je n’en suis pas encore à la fin, même si le qualificatif de malheureux convient assez bien. Je ne suis pas certain que le module jalon soit modifié à chaque version. A la question pourquoi un seul module provoque cette situation, je répondrais que ce dernier me sert à construire des offres structurées avec des jalons, sous lesquels j’entre les produits dans mes propositions commerciales. Désormais, sous D 3.8.0, la génération du PDF d’une telle offre conduit à une absence de prix. J’ai donc voulu inactiver Jalon, ce qui efface de l’offre tous les produits intégrés à des jalons.
Donc si demain un client accepte l’une de mes offres avec jalon, je dois tout resaisir. Si je veux cloner une offre avec jalon, cela devient impossible. Autrement dit je perds beaucoup d’informations et de temps.
@Philazerty,
J’ai migré vers la 3.8 en voyant apparaitre la possibilité de gestion des numéros de lot et de série pour les produits, question d’actualité pour moi. Quant à la question de l’accompagnement, cela est envisagé depuis un moment déjà. Cela sera mis en place quand les finances de la société le permettront.
A bientôt.
Bonjour,
je trouve aussi ce témoignage intéressant.
Merci de rappeler que les utilisateurs de Dolibarr sont des entreprises dont l’objectif est de faire des affaires et non pas de l’informatique.
C’est souvent mal compris : un migration d’un outil en production présente un risque et exige de la méthode. La principale étant de ne pas bloquer l’application et pouvoir continuer de travailler même si ça se passe mal.
Mail il est vrai qu’un entrepreneur n’a pas toujours le temps, ni les compétences pour réaliser une migration offrant toutes le garanties de sécurité.
Avec la multiplication de modules externes, les migrations deviennent forcément plus complexes et risquées.
Donc il faut devenir plus prudent et s’assurer d’abord qu’on peut continuer à travailler.
Bonjour TIARIS,
Merci de votre message, rappelant que le but ultime de l’application, est d’être fonctionnelle.
A mon sens, les modules externes devraient être testés lors des mises à jour de Dolibarr par leurs éditeurs respectifs. Avant téléchargement, nous, les utilisateurs non développeurs, pourrions ainsi agir en connaissance de cause.
Une sorte de « Attention, vous allez gagner ça mais perdre ça ». Ce pourrait être présenté sous forme de tableau et tout un chacun pourrait vite voir si la mise à jour proposée a été testée avec les modules qu’il utilise…
En tout cas, moi, cela m’aurait été utile.
Et bien, après beaucoup de temps passé à essayer de comprendre, à modifier, tester…etc, une solution s’impose : retour à la case départ : version 3.6.3 en ce qui me concerne.
encore une fois, merci à Monsieur Grand pour son aide.
Pour résumé la situation des dysfonctionnements observés sur la 3.8.0 et .1 :
- perte des liens photos sur les fiches produit,
- dysfonctionnement du module Jalon et le module sous total ne me permet pas de le remplacer efficacement (pour mon utilisation),
- module marge qui semble modifier des prix tout seul
- et que sais-je encore…
Alors voilà, ma solution, c’est de ne plus faire de mise à jour !
Oui, vous avez raison, chaque éditeur doit s’occuper de la migration de ses modules. On n’arrète pas de le répéter aux vendeurs de modules sur dolistore. Et nous avons des règles assez strictes.
Mais il incombe aussi au responsable de la maintenance de Dolibarr (l’utilisateur ou un prestataire) de s’en assurer. Comme Dolibarr est libre, et que tout un chacun peut l’installer et en faire ce qu’il a besoin, il n’y a pas d’autre solution.
J’espère pour vous que les bugs que vous avez rencontrés vont être corrigés et que vous puissiez faire votre migration sereinement ensuite.
Je rebondis au sujet de la maintenance des modules, pour vous parler d’une soucis que j’ai eu lors de la sortie de la 3.7.0
j’ai passé une semaine à tester sur la version béta pour me rendre compte à la sortie de la version définitive un changement de dernière minute sur la gestion des extrafields : tous mes modules utilisant cette fonctionnalité était planté…
Dorénavant j’attends donc la sortie de la .0 officielle pour commencer mes tests et j’explique gentiment à mes clients/utilisateurs de ne pas utiliser cette nouvelle version avant la sortie de la suivante (ou alors pour faire joujou sur un environnement de qualification).
Je persiste à dire que mettre en production une version de dolibarr estampillé en .0 c’est juste jouer à la roulette russe avec son entreprise.
Sinon pour votre besoin de lot et numéro de série en vous proposant de regarder le module Equipement qui permet de gérer ce genre de chose (et un peu plus encore).
Merci à tous.
Je suis en train de revenir à la 3.6.3. Espérant que ça soit un retour gagnant.
Le prochaines mises à jour seront faites par un prestataire en ce qui me concerne. Néanmoins, et même si je reconnais mes tors d’avoir mis à jour sans contrôle préalable, je ne conçois pas que des fonctions aussi basiques que la gestion des photos produits ne soient pas vérifiées avant sortie.
Cordialement.
@Charles Alors qu’il suffirait d’une simple période de RC d’ 1 mois ou 2…
Bonjur,
Juste une remarque que j’ai déjà faite ailleurs:
Vu le rythme très soutenu des sorties de versions de dolibarr, je n’ose pas imaginer le temps qu’il me faudrait pour tester chacun de mes modules et les mettre à jour dans les temps puisque le coeur de Dolibarr est sans cesse modifié sans rétro-compatibilité la plupart du temps, les fonctions renommées, ainsi que les champs de la base, etc… bien sûr dans un but louable (avoir un code plus propre, plus standard, etc) ou moins louable (changer les noms de variable ou de la base de données pour les passer en anglais - honte de ses origines ?).
Bref, ces sujets ont été abordés ailleurs (et en vain) depuis longtemps… pour finir ma phrase, avec deux versions majeures par an qui remettent pas mal de choses en cause à chaque fois, il est difficilement envisageable de suivre le rythme si on a une dizaine de modules à faire évoluer, à moins bien sûr de les vendre beaucoup plus cher et de ne vivre que de ça…
Moi j’ai des clients, avec plein de demandes d’évolutions, de nouveaux modules, etc et ce sont eux qui me font vivre; j’ai également une trentaine de modules dans les cartons qui sortent au compte-goutte, ou ne sortiront surement jamais; dommage pour les utilisateurs potentiels et dommage pour l’association dolibarr qui prend 20% des ventes de chaque module et pourrait mieux promouvoir son néanmoins très bel outil avec cet argent (et j’imagine que je ne suis pas le seul dans ce cas).
La fuite en avant vers les nouvelles versions n’est pas uniquement la faute aux utilisateurs (regardez ce qui est écrit en haut à droite de la page d’accueil de dolibarr.fr, sous la boite de recherche)
Pièces jointes :
- stable.png (69.7 KB)
Bien sûr, cela nécessite un travail important de tester les modules complémentaires. Enfin, j’imagine, je ne suis pas développeur.
D’où l’idée d’avoir un tableau très simple et accessible à chaque utilisateur sur la page de téléchargement de Dolibarr, tableau dans lequel chaque version de Dolibarr serait indiquée en titre de colonne, et chaque module ou version de module en ligne. Des croix en face des versions de Dolibarr informerait tout utilisateur non développeur de la vérification ou non de ses modules de travail sur une version de Dolibarr.
Un tel tableau pourrait être renseigné par chaque développeur à l’issu de ses essais.
Dans mon cas, je vérifierais avant mise à jour que les modules Marge, ReStock, Jalon et UltimatePDF ont bien été vérifié. Dans le cas contraire, je patiente en évitant de grosses bêtises et pertes de productivité.
Pour parler de mes modules, tous ne sont pas encore passé les tests de validation sur la 3.8
l’un d’eux (customTabs) n’est d’ailleurs plus compatible, je suis en train de regarder comment gérer le soucis sans toucher au core (et je peux vous dire que c’est parfois loin loin d’être simple…)
Quand l’un d’eux est bon je change juste sur sa fiche sur le dolistore son niveau de compatibilité.
@sterwen: bonne idée !
Notez juste que le module Marges a été intégré au coeur de Dolibarr depuis la 3.3 si j’ai bonne mémoire (j’en suis à l’origine), même s’il apparait toujours dans les modules complémentaires, et qu’il est censé être maintenu comme les autres modules du core.
J’en profite pour préciser qu’avec ce rythme de version, il est quasiment impossible de développer un module en vu de son intégration puisque les temps de développement d’un (gros) module sont souvent supérieurs à 6 mois. (Je me souviens avoir passé un temps fou à adapter le module marges et la gestion des taxes locales pour qu’ils soient intégrés dans le core)
bonjour.
je rejoins un peu les dev pour le fait que tout les 6 mois une nouvelle version « stable » avec son lot de changement aléatoire qui oblige de faire des modifications du module qui le rende incompatible avec les version précédente (surtout sur le changement de nom des colonnes de la bases de données) du coup ca oblige de maintenir plusieurs version
tout ca pour dire que c est normal que les modules externes prennent un peu de temps a etre mise a jour vu cette course a la version inutile et contre productif pour les dev externe …
a quand une LTS sur lequel on pourrais bosser sereinement
sans compter que l’on tente tant bien que mal à n’avoir qu’une seule version de nos modules compatible avec le plus de version de dolibarr possible
A ce sujet je viens de rajouter un beau « if (DOL_VERSION < ‹ 3.8.0 ›) » dans le code de customLink pour gérer justement une évolution de la gestion des hook dans la version 3.8.0
Bon j’ai aussi trouvé un bug sur la gestion des éléments liées : https://github.com/Dolibarr/dolibarr/pull/3742
c’est vrai que j’aimerai bien passer plus de temps à travailler sur les évolutions du noyau (en particulier dans le refactoring pour faire plaisir à jfefe) que prendre du temps à maintenir mes modules à chaque changement de version. Avec 14 modules je me demande comment j’y arrive d’ailleurs…
@defrance: je viens d’aller regarder le changelog pour cette histoire de hooks… bon ben moi aussi j’ai du boulot… qui décide ce genre de c… ?
surtout que ce serait plus simple de garder les anciennes methodes avec un message dans le log pour dire qu il y a du changement plutot que de faire les bourrins a supprimer et de foutre le bordel dans les modules existant ce qui laisserait 6 mois au dev de corriger plutot que de bosser dans l urgence …
@icfr: c’est ce que je dis régulièrement, mais sans effet notoire à part peut-être parfois « oui tu as raison » non suivi d’effet. Le souci c’est de savoir qui décide de faire ceci ou cela, quels sont les critères pour qu’une modif soit intégrée, quelle réflexion y’a t’il sur ce genre de modif sensée harmoniser le code ou le rendre conforme à une méthode parfois discutable (y’a t’il eu discussion ?), quelles sont les priorités de développement (roadmap?), etc, etc
Bonjour Sterwen, bonjour à tous,
J’ai un peu moins d’années de production sous Dolibarr mais parfois je me pose les mêmes questions que vous…
De mon coté j’avais déjà des bugs sous Jalon avant la montée de version et me passer de Jalon n’était pas possible alors ca a été dur mais j’ai attendu (comme le prône aspangaro ) … et je suis resté figé 1 an avec mon Dolibarr en 3.6.2…
Mais c’est peut être le bout du tunnel, je viens de répondre au fil de discussion que j’avais lancé sur le sujet, peut etre devriez vous y participer ?
cf : www.dolibarr.fr/forum/t/en-finir-avec-jalon-milestone-action-commune/21431/1
Au passage comment s’est passé le downgrade en 3.6.3 ? ou en êtes vous maintenant ?
Au plaisir de vous lire.
Bonne soirée,
Bonsoir,
Merci pour votre message. Je vais aller jeter un oeil à ce fil !
Je suis en effet revenu à la version 3.6.3 de la façon suivante : avant chaque modif de Dolibarr, je sauvegarde ma base de données, puis l’ensemble du répertoire Dolibarr. Ainsi, en cas de problème, ce qui a été le cas, je peux revenir en arrière en restaurant la base, puis l’ensemble des fichiers du répertoire.
Mais comme vous, j’ai des bugs à différents niveaux, avec lesquels j’ai appris à vivre…
A bientôt et bonne soirée également.
Sterwen
