DevCamp Lyon 2023 hiver

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

• Tailwind (https://tailwindcss.com/)
• Onsen.io https://onsen.io/
• Bootstrap https://getbootstrap.com/
• Bulma https://bulma.io/

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 :

• Besoin d'un token par utilisateur permettant de délimiter les fonctions accessibles parmi celles possibles pour l'utilisateur.
• Besoin d'un service Worker -> https://developer.mozilla.org/fr/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Offline_Service_workers
• Intégration à Module Builder.

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.