DevCamp Lyon 2023 hiver

2023-11-21T08:31:24Z

Kazimir42: Correction email

==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

*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 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.lu
- Clarisse Thomas - t.clarisse@vold.lu
- 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 :

*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:

[[File:Proposition de version LTS.png|thumb|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.

Dolibarr ERP CRM Wiki - User contributions [en]

DevCamp Lyon 2023 hiver