DevCamp Lyon 2023 hiver

From Dolibarr ERP CRM Wiki
Revision as of 07:04, 21 November 2023 by P.scoffoni (talk | contribs)
Jump to navigation Jump to search

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 testé 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 Builder 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éférence ($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=58796"