DevCamp Lyon 2023 hiver

Prise de notes lors des différentes tables ronde

FACTURE DE SITUATION

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

Proposition de compte rendu pour la table ronde UI/UX

CODE 42 : 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é Suivi du projet :

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

John : Proposition autour de JS et de l'interaction entre module externe @johnbotella Proposition de partager du JS entre module externe Heberger et standardiser les interfaces UI/UX (A priori dans public/test) afin qu'elles soient visibles de tous (comme la documentation de Onsen.ui (https://onsen.io/theme-roller/) fontawesome, etc... Code 42 : Propose la possibilité d'utiliser des outils comme figma https://www.figma.com/ Il faudrait faire intervenir un spécialiste externe UI/UX

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) https://www.eoxia.com/comparaison-doutils-pour-creer-un-onepage-html/ Proposition de travailler sur 2 axes 1 axe Expert IHM 1 axe de nettoyage, preparation du code permettant d'accueillir les évolutions à venir

Iouston : Intégration de composant natifs déjà pensé et stabilisé Proposition d'intégration en natif d'autres framework 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 Illustration du passage a de nouvelles version php, l'évolution c'est fait petit à petit

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
       -> Definition 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érencer les pages d'edition, de création et de vue niveau de la fiche
       - se baser sur le CRUD -> create - edit - delete

- 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 maj dans la prochaine version Dolibarr

- Navigation

       - Menu: manque de structure pour savoir ou on est
       - Breadcrumb ? Fil d'arianne ? Ou je me situe par rapport ou j'etais avant. Usernav history

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

APPLICATIONS MOBILES

Eric (CAP-REL)

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 PR

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

Problématique iOS est contraint Apple Store

Obligation d'avoir 2 Iphone, 1 mac pour compiler avec les bonnes versions de logiciel

PWA :

Pas de restriction par rapport au pilotage du matériel du smartphone

Https requis

>> Nouveau GIFF à créer !

-> déjà fait: 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 - (Alexis De Lattre - Odoo ? - https://www.linkedin.com/in/alexisdelattre/)

Voir https://fnfe-mpe.org/

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

Retour expérience EASYA-SOLUTIONS v2020 basé sur DOLI10 - v2022 basé sur DOLI14 - v2024 basé sur DOLI18

Grace à cela, il assure un MCO / SOFTWARE ASSURANCE sur leurs environnements. Ils font des backport sur DOLIv14 . Des mises à jours/ 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

Objectif : 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 release 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é
• Version intermédiaire : Tous les 6 mois incrément de +1
• Version corrective si CVE ou bug fonctionnel grave

Charte 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 fix
• 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.

Pour chaque branche, 1 mainteneur principal porté par un intégrateur + padawn backup d'un autre intégrateur