Il semble qu’il y a eu une mise à jour du dolistore cette semaine… Résultat : il ne m’est plus possible de mettre en ligne mes modules sur sur le dolistore :
C’est bien gentil vos règles à la C…N mais comment on fait par exemple pour utiliser une librairie qui est utilisé par un autre modules?
cas d’école pour des onglets d’équipements présent dans le module factory?
Je viens d’envoyer un mail
C’est quand même inadmissible qu’un minimum de communication ne soit pas fait au gros contributeurs de modules. Je verse 4000/ans de commission, participe à tous les devcamp et on se prend ce genre de chose dans la gueule sans prévenir !!!
Hello Charlène,
Copie du message au bureau de la part de Laurent hier :
[quote]
Comme annoncé lors du devcamp, j’ai blindé dolistore pour ne plus accepter les modules suffisemment mal conçu pour qu’il ne se déploie pas via l’outil « Deployer module externe » en standard dans dolibarr. J’analyse l’arborescence du module, mais aussi le code pour bloquer les mauvais usages des include ou dol_include_one. Normallement un message d’erreur vous averti dès la soumission du module ce qu’il faut corriger. Ne soyez donc pas surpris si vos modules passeit avant et plus maintenant…
Pour l’instant les controles sont sur les regles de nommages du zip, des repertoires qu’il contient et de la bonne gestion du custom dans le code.
Dolistore vérifie le contenu des modules ?
[quote=« aspangaro-OpenDSI, post:3, topic:30355 »]
Hello Charlène,
Copie du message au bureau de la part de Laurent hier :
Ben si je suis surprise et quelque peu furieuse de ce manque de communication pour ne pas dire professionnalisme!!!
Que je sache tous les développeurs de modules ne sont par au « bureau », sans parler qu’un minimum de tests sur par exemple le TOP 10 des modules les plus diffusées sur le Dolistore aurait du être fait!
Eldy nous fait des gorges chaudes à chaque devcamp sur l’écosystème de dolibarr, ben il faudrait qu’il respecte un minimum la communauté qui contribue a faire vivre (et vivre de ) Dolibarr!!!
Merci de supprimer au plus vite cette contrainte QUI NE SERT A RIEN et qui est contre-productive en terme de qualité, sans la possiblité d’appeler des librairies d’autres modules présent, cela revient à dupliquer l’ensemble des librairies pour chaque modules…
A la question « comment on fait par exemple pour utiliser une librairie qui est utilisé par un autre modules? », voici une réponse qui, bien qu’évident, semble utile à redonner:
« On fait comme on fait les autres : On envoie un email, comme cela est suggéré dans le message d’erreur de dolistore, pour avoir une démarche constructive et courtoise afin de faire corriger le bug d’analyse. »
Pour adefrance, ce n’est pas moi qui est réclamé cette tache. Elle fait partie des taches mise dans le pipe des taches à faire, alimentés par l’association il y a maintenant de très très nombreux mois (La tache nommé « Contrôle qualité automatisé des modules DoliStore » avait été saisie début 2018 et programmé pour le 01/09/2018). Je l’ai réalisé en tant que sous traitant pour le commanditaire qui est l’association Dolibarr (le projet est suivi dans la gestion de projet dolibarr de l’asso).
Il vaut mieux donc s’adresser à l’association qui gère le Dolistore pour s’en prendre aux choix de ses actions et priorités, plutôt que d’accuser des personnes nominativement. Ne pas savoir, c’est normal, ne pas sans se renseigner, cela l’est moins…
Mail de ce matin :
Pour ma culture perso :
c’est quoi le changement ?
un process de validation avant mise en ligne ?
c’était pas du tout fait avant ? en quoi consiste ce process ?
en quoi ça à fair ragir charlie de la sorte (les délais sont plus long entre post/mise approbation) ?
Ce qui me fait réagir, c’est l’absence TOTAL de communication envers les diffuseurs de modules, on fait des modifications importantes en pleine vacances
Si demain par exemple on ajoute des contraintes de types qualité de code (application de psr, règle de codage et de structuration, …) sans prévenir personnes (et je précise que cette communication DOIT se faire dans le sens dolibarr vers communauté) et que l’on se prend un mois dans les dents à modifier nos sources pour les remettre en vente, on fait comment avec nos clients, famille, …
Pour parler de choses comparables, je n’imagine pas l’applestore ou androidplay changer les règles d’acceptation des applications du jour au lendemain sans la moindre communication aux principaux développeurs de module. Je le rappel, j’assiste à tout les devCamp et il n’a pas été question de tel règles mais de « règles sans les préciser » alors, de plus je me demande comment une règle aussi stupide a-t-elle pu être demandé et comment Eldy qui est loin d’etre un « bleu » a pu la développer sans réfléchir à son impact.
Alors oui, il y a de nombreux bénévoles qui oeuvrent pour dolibarr (et encore il me semble que ce n’est plus le cas, l’époque du groupe de « barbues » de 2012 a été remplacé par des gus en costard lors des devcamp).
Il faut sans doute revoir le cadre de ses conventions, les développeurs ont besoins d’informations techniques lors de ses évènements, pas de comm sur le fait que dolibarr est capable de faire « aussi bien? » qu’odoo alors que l’on ferai mieux en mon sens de continuer de faire aussi bien du dolibarr.
Bref, c’est la goutte d’eau qui fait déborder le vase et me fait penser il est peut-être temps de changer certaines choses …
ok je comprends un peu mieux ton point de vue.
Je te rappelle juste au passage, que c’est toi qui m’a demandé de t’appeler Charlie lors de notre dernier coup de fils (peut être même le seul)
mais si tu préfère Charlène maintenant, no pb 
(mais Charlie t’allais bien : et j’espère que tu rapelles pourquoi : j’ai un « Charly » à la maison)
En tout cas, merci pour ton implication, mais soit moins « incisifs » dans tes propos : comme tout le monde est bénévole, ben les choses tombent quand elles tombent …
je rejoint quand même ton sentiment (et le sentiment général qui commence à poindre de toute part…) : le projet manque de leader ship et de communication.
mais là aussi c’est normal : c’est un job à temps plein et actuellement (si j’ai tout compris) non rémunéré.
J’espère avoir le plaisir de t’avoir en vocal sur le discord un de ces 4. (https://discord.gg/pPNu2D) : sinon tu dois avoir mon tel.
Et et pouvoir tous vous rencontrer lors d’un des prochains « dev camp » (je déteste cette appellation, qui par définition ne laisse pas de place aux users 
)
Disons que les choses dans ce domaine sont acté à présent 
…
Parfois il faut secouer le cocotier pour faire avancer les choses et je ne suis pas du genre effectivement à prendre des pincettes quand cela ne va pas!
C’est sans doute bien cela le sujet, le coté bénévole n’est sans doute plus possible avec les sociétés et personnes qui gagnent à present leur vie grâce à Dolibarr…
Et l’idée de faire passer une grenouille (dolibarr) pour un boeuf (odoo) est à mon sens un péché d’orgueil, beaucoup d’énergie est dépensée actuellement pour « tout faire comme Odoo » aux détriments de la qualité et du refactoring; on a rajouté une fonction pour gérer un site web dans dolibarr et en faire un énième CMS alors que les éditions pdf sont toujours catastrophique…
pour la comparaison odoo/dolibarr: je ne suis pas d’accord :
d’un coté, il y a une société qui mène le projet, et qui maintient une commu. (odoo)
de l’autre (dolibarr) : ben y’a que la commu, de bonnes volontés et des entreprises qui tentent d’en vivre.
le coté « bénévolat » : chacun en fait son histoire.
moi par exemple, j’ai la chance d’avoir des activités rémunératrices, sans que cela m’accapare trop de temps : le TEMPS que je « donne » à dolibarr est un « remerciement » pour ce dont j’en fait (et on va pas se le cacher … je suis un peu geek sur les bords )
Concernant les notions de CMS ou de gouvernance du projet : je suis un des moins bien placé pour en parler.
Ou Eldy prend le taureau par les cornes, ou il délègue (et il faudrait trouver la bonne personne…)
Je comprends ta « rage » d’assister à ça, surtout en temps qu’entrepreneur : mais rien ne se résoudra sur un forum ; il faut se parler se rencontrer, discuter
Bonjour Charlène,
Je confirme que depuis un bon moment, l’asso souhaite que les modules mis en vente sur le Dolistore soient contrôlés. Il y a de + en + de ventes (tant mieux pour tout le monde) et donc de + en + de retours par e-mail auprès de l’asso. Un de nos objectifs est de réduire le temps administratif passé pour l’asso. Les e-mails concernant des modules du Dolistore représentent une grosse partie de ces e-mails. Donc pour réduire ces retours, nous mettons en place des contrôles sur les modules proposés par les développeurs. C’est justement un point qui montre qu’on se professionnalise.
Comme indiqué par @eldy, ces contrôles existent dans Dolibarr depuis la V6 lors du déploiement d’un module via l’onglet « Déployer/Installer un module externe ». Jusqu’à présent sur le Dolistore, seul le nom du fichier était contrôlé. Nous avons souhaité que les contrôles fait par Dolibarr soit également fait sur le Dolistore.
Un petit mail à l’asso pour signaler que les contrôles semblent trop stricts aurait été plus constructif qu’un message public incendiaire sur le forum… Ceux qui bossent pour l’asso, son amélioration, sa professionnalisation, ont besoin de soutien constructif et pas de se faire tacler au moindre changement.
Bref, on doit tous toujours s’améliorer, notamment sur la communication…
En fait, il n’y a pas vraiment de changement. Les règles et process sont les même.
Par contre, du code « nettoyé » pour valider en temps réel la soumission d’une mise à jour de module, qui normalement devait avoir un impact mineur, voir aucun, a fait apparaitre une erreur sur la page de soumission de modules pour certains, bloquant l’upload du module de manière injustifié. Certains n’ont malheureusement pas pris le temps de lire le message d’erreur qui apparaissait demandant d’envoyer leur module pour un débuggage et information en cas de problème et ont cru à des changement majeurs. Depuis le bug a été corrigé.
Voici un résumé de ce qu’il y avait avant
- validation du nom du zip (code dupliqué avec celui de dolibarr et différent de celui de la fonction « déployer un module externe » de dolibarr v6 à 10. L’ancien dolistore refusant les versions qui n’avait pas au moins 2 composants x.y)
- validation de la bonne compatibilité avec l’usage du module en /custom (désactivé si ce n’est pas un module dolibarr mais il ne se déclenchait pas toujours quand le module était un module dolibarr)
Voici un résumé de ce qu’il y a maintenant (on retrouve les 2 points)
- validation du nom du zip (code identique à celui de la fonction « déployer un module externe » de dolibarr v6 à 10, acceptant les version avec 1 seul composant ou plus).
- validation de la bonne compatibilité avec l’usage du module en /custom (qui se déclenche maintenant sans passe droit quand le module est un module dolibarr)
Un bug était par contre apparu suite au merge et alignement du code entre dolibarr v6-10 et dolistore, mais a été corrigé dès sa découverte. On a en effet pas fait de communication publique en avance sur l’apparition de cette régression, ne pouvant anticiper le bug, d’autant qu’il ne se manifeste que sur certains modules uniquement (La plupart des modules phares de dolistore avait été testé et n’avait pas fait apparaitre cette regression).
rien n’a changé, ni en terme de délai ni en terme de règle de codage (toujours celle initialisée et communiquée en 2013). Les messages en cas de problèmes sont par contre plus clairs et plus apparents.
Pour info, le code de dolistore étant un outil maintenu par l’association, il est donc libre et visible sur le github de l’assocation. Pour le module qui gère la soumission de modules dolistore, c’est dans : https://github.com/Dolibarr/foundation/blob/develop/dolistore/
