Dolibarr ERP CRM Wiki

DevCamp Lyon 2023 hiver

Revision as of 07:00, 21 November 2023 by P.scoffoni (talk | contribs)

Prise de notes lors des différentes tables rondes

Facture de situation

Réalisé par Progiseize Validation des tests de la migration des données vers le nouveau modèle de données Propositions :

  • Ajouter une étape de contrôle d'intégrité post-migration des données (Action Easya Solutions)
  • Réaliser PR Dolibarr pour intégration v20

Gestion des interfaces UI/UX

Réalisé par Code42 Proposition de hiérarchie et charte de nommage associé (@Code 42 : Pourrais-tu envoyer ta présentation)

llx_headers construction de classe optimiser en fonction de l'endroit où l'on se situe dans le body. Réaliser un plan de nommage standardisée Suivi du projet : 

       -> Issue liste top-priority
       -> Travail en petite communauté
       -> Définition d'un GIFF

Propositions autour de JS et de l'interaction entre module externe @johnbotella Proposition de partager du JS entre modules externes

Proposition Eoxia : Héberger et standardiser les interfaces UI/UX (A priori ce type d'interface existe en prototype dans le dossier dolibarr natif "public/test") afin qu'elles soient visibles de tous (comme la documentation de Onsen.ui (https://onsen.io/theme-roller/) fontawesome, etc... Proposition de travailler sur 2 axes :

  • 1 axe Expert IHM
  • 1 axe de nettoyage, préparation du code permettant d'accueillir les évolutions à venir

Échanges : Code 42 : Propose la possibilité d'utiliser des outils comme figma https://www.figma.com/ Faire intervenir un spécialiste externe UI/UX afin d'attaquer le sujet par la fin

Eoxia : Nous étudions des possibilités de réaliser des sites simples sans aucune maintenance avec des outils comme ceux tester ci-dessous (dont Figma). Il existe de nombreux autres outils nous avons commencé un comparatif ici : https://www.eoxia.com/comparaison-doutils-pour-creer-un-onepage-html/

Iouston : Intégration de composants natifs déjà pensés et stabilisés Proposition d'intégration en natif d'autres framework comme

CapREL Proposition de travailler en itératif par petite étape, l'illustration du passage à de nouvelles versions PHP, l'évolution, c'est fait petit à petit. Cette méthode permet d'avoir des résultats rapides très complémentaires à une approche globale qui vise uniquement le résultat final souhaité.

UI Code 42 : Intégration dans le Bulder des nouvelles fonctions d'IHM

>> Nouveau GIFF à créer !

Suite Table ronde ui/ux

Participants: - Amine Labghali (BigData Consulting - anexys) : amine@anexys.fr - John Botella (ATM) :: john.botella@atm-consulting.fr - Clémence Cros :: c.cros@totemnumerique.com - Reaux Kevin - hello@krikrak.fr - Champlon Remi - r.champlon@vold.lv - Clarisse Thomas - t.clarisse@vold.lv - Anthony Damhet - a.damhet@progiseieze.fr

Les sujets abordés sont :

- L'ajout de classes CSS à Dolibarr: 

       -> classes enfants class --subclass
       -> Définition d'un id html avec les objets (class=thirdparty id=thirdparty-211)
       - class avec le nom de la classe du descripteur du module
       - .mod_nommodule .page_list
       - --------------- .page_card
       - --------------- .page_dashboard
       - Différencier les pages d'édition, de création et de vue (MVC) au niveau de chaque fiche basée sur le CRUD

- Modification du hook "change_help_url" en llxHeader 

       -> Passer plus de paramètres en réference ($parameters = array('head' => &head))
       -> Avantage: + Rapide pour passer les mises à jour dans la version suivante Dolibarr

- Navigation 

       - Menu: manque de structure pour savoir où on est
       - Breadcrumb ? Fil d'ariane ? Ou je me situe par rapport ou j'étais avant. Usernav history

- Faire les modifications dont on a besoin dans le module Builder pour intégration future - Liste -> 1 identité - Nomenclature / Accessibilité (data-attribute) - Fonction wrapper des listes

Applications mobiles et Progressives Web Applications PWA

Réalisé par Eric (CAP-REL) Les besoins identifiés suite à la réalisation d'application PWA :

Big Data Consulting (Anexys) : Réalisation d'une application hybride en React Native (déjà en PROD)

VOLD : Réalisation d'une application mobile en mode déconnecté

4 Pull Request à lancer

  • Token utilisateur
  • Evolution Module builder
  • Worker
  • Exemple implémentation appli mobile

Problématique IOS est contraint Apple Store

  • Obligation d'avoir 2 Iphones (1 test, 1 production)
  • 1 mac pour compiler avec les bonnes versions de logiciel
  • Le risque de se voir retirer facilement son application du store

Il existe de nombreux avantages :

  • Pas de restriction par rapport au pilotage du matériel du smartphone
  • Pas de dépendances des stores
  • Simple à mettre en place
  • Accessibilité au HardWare

>> Nouveau GIFF à créer ! Eoxia : Le GIFF est déjà existant ici : voir GIFF - Socle Technique Mobile reste à établir les participants, le budget, les délais & objectifs etc.

Facture X

Eoxia : Est-ce que nous avons des contacts au sein du ministère ou de la commission normative des factures afin d'être informé des évolutions et y participer ?

CAP REL Propose de contacter Alexis De Lattre - Odoo ? -> https://www.linkedin.com/in/alexisdelattre/

Voir le groupe de travail https://fnfe-mpe.org/ et proposition que l'association Dolibarr y adhère ?

Page des spécifications

https://www.impots.gouv.fr/specifications-externes-b2b

John et Nicolas : Proposer une priorisation des Hooks afin de permettre la gestion des priorités d'actions

DOLIBARR LTS

Retours expériences EASYA-SOLUTIONS v2020 basé sur DOLI10 - v2022 basé sur DOLI14 - v2024 basé sur DOLI18

Grâce à cela, il assure un MCO / SOFTWARE ASSURANCE sur leurs environnements. Ils font des backports sur DOLIv14 . Des mises à jour/ PR, sont encore intégrées / validés dans Doliv10.

Des évolutions sont aussi apportées dans EASYA2022. Par ex. Dans la v2022, la GPAO v17 est intégrée + la compatibilité DOLIBARR v20.

Le discours officiel de DOLIBARR : support seulement de 3 versions : N, N-1, N-2

Objectifs :

  • Inciter à la publication de FIX avec une équipe LTS
  • Accompagnement/Formation à la réalisation de PR

Définition de la notion de LTS

  • Rythme : Une LTS tous les 2 ans
  • Durée : 5 ans
  • Publication de releases sur le dépôt principal Dolibarr
    • Note: Doliwamp, packages, sourceforge : non maintenu par l'équipe LTS
  • Version Min/Max PHP à préciser sur chaque LTS
  • 3 périodes sur les 5 ans
    • A, A+1 FIX + (NEW type évolutions Module Builder)
    • A+2 FIX sécurité et fonctionnels et FIX compatibilité modules
    • A+3 à A+5 FIX sécurité et fonctionnels

Proposition de numérotation des versions LTS

  • Version majeure : inchangée
  • Version intermédiaire : Tous les 6 mois incrément de +1
  • Version corrective si CVE ou bug fonctionnel grave

Charte du mainteneur (à établir)

Outils de maintenance associés aux versions LTS : Upgrade du core automatique ?

Sortie de la LTS 6 mois après la sortie de la version N

Exemple :

  • v18.0.0 sort à la date x
  • v18.0.1 ... v18.0.x sortent comme d'habitude
  • v18.1.0 LTS sort lors de la publication de la V19.0.0
  • v18.1.1 publié lorsqu'un fix sécu/important est mergé sur la branche 18
  • v18.1.2...v18.1.x au gré des fixs
  • 6 mois après v18.1.0 publication de la v18.2.0
  • v18.1.1....v18.1.x au gré des fix
  • 6 mois plus tard v18.3.0
  • etc.

Visuel peut-être un petit peu plus parlant:

 
Proposition de ce que pourrait être la roadmap dolibarr avec version LTS - résultat du groupe de travail "LTS" du devcamp Lyon 2023

Pour chaque branche,

  • 1 mainteneur principal porté par un intégrateur + padawn
  • 1 mainteneur en backup d'un autre intégrateur.
Retrieved from "https://wiki.dolibarr.org/index.php?title=DevCamp_Lyon_2023_hiver&oldid=58794"