View source for 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 à faire évoluer pour permettre l'usage de classe CSS optimisées 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

<br />

=== '''Communication''' ===
Réalisé par Eoxia : Amélioration de la communication externe pour les salons. Explication du fonctionnement d'autres projets notamment comme la communauté WordPress

* Pour les salons : Proposition de mettre en place un village Dolibarr avec la participation des Entreprises/personnes au sein de ce village
* Pour les DevCamp :  Proposition de faire une journée utilisateur devant le DevCamp
* Pour soutenir les évènements proposition de faire intervenir des sponsors de matériel, d'hébergement, etc...

Il a été soulevé par les permanents de l'association un besoin de ressource qui permettrait de réaliser les actions internes nécessaires au bon fonctionnement de l'association.

Il y a eu de nombreux échanges autour de ces points : La communication doit être professionnelle

La création d'une commission concernant la communication serait un bon point de départ afin de faire des propositions à l'association.
<br />
===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 : Il est recommandé d'intégrer les bug fix jusqu'à N-2 (car simplifie la vie du développeur de ne pas remonter trop loin), mais tout bug fix, soumis dans une version même très ancienne de Dolibarr est intégré. Toutes les versions de Dolibarr font donc déjà l'objet d'un processus LTS. Par contre, dans les faits, peu de développeurs soumettent des correctifs sur des versions au delà de 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.

=> Question de LDR post-réunion: Pourquoi si compliqué ? Pourquoi tout simplement pas 18.0.1 puis 18.0.2 puis 18.0.3 etc... et ce simplement durant une durée allongée ?

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 (Jedi + Padawan)
*1 mainteneur en backup d'un autre intégrateur.

=> Remarque de LDR post-réunion: Ces postes, pour maintenir les versions n-1, n-2 et n-x sont ouverts depuis plusieurs années déjà (Ils ont été nommé "Jedi", voir la page ([[Projet_Dolibarr#D.C3.A9veloppeur_grade_Jedi_.28Release_manager_versions_de_maintenance.29]]). Etre Jedi nécessite des compétences en matière de merges et de résolutions de conflit GIT, une bonne connaissance générale de l'application, et savoir aussi orienter la correction du code au strict minimum du Fix. Quelques développeurs se sont essayés par le passé, mais hélas la motivation n'a pas durée. Les postes sont donc toujours ouvert...

=Session To Merge or Not To merge=
Faute de temps, la session "To Merge or Not To Merge" visant à initier au métier de "Mergeur" via un jeu basé sur des cas réels sur lesquels se prononcer, suivi de l'explication de la réponse qui a été retenu n'a pu se faire (A la fois faute de temps pour assurer la session mais aussi sa préparation qui n'était pas complètement terminée). Cette session est donc remise au prochain devcamp...