DevCamp Lyon 2023 hiver: Difference between revisions

DevCamp Lyon 2023 hiver (view source)

Revision as of 20:39, 20 November 2023

913 bytes added , 2 years ago

Mise à jour du contenu et de la forme

VisualWikitext

LaurentM

353

edits

@@ Line 1: / Line 1: @@
-==Prise de notes lors des différentes tables ronde==
+==Prise de notes lors des différentes tables rondes==
-===FACTURE DE SITUATION===
+===Facture de situation=== Réalisé par Progiseize
-Ajouter une étape de contrôle d'intégrité post migration des données (Action Easya Solutions)
+Validation des tests de la migration des données vers le nouveau modèle de données
-Réaliser PR Dolibarr pour intégration v20
+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
-===Proposition de compte rendu pour la table ronde UI/UX===
-CODE 42 : Proposition de hiérarchie et charte de nommage associé
+===Gestion des interfaces UI/UX=== Réalisé par Code42
-@Code 42 : Pourrais-tu envoyer ta présentation
+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é
+Réaliser un plan de nommage standardisée
 Suivi du projet :
-   Issue liste top-priority
+        -> Issue liste top-priority
-    Travail en petite communauté
+        -> Travail en petite communauté
-    Définition d'un GIFF
+        -> Définition d'un GIFF
-John : Proposition autour de JS et de l'interaction entre module externe @johnbotella
+Propositions autour de JS et de l'interaction entre module externe @johnbotella
-Proposition de partager du JS entre module externe
+Proposition de partager du JS entre modules externes
-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)
+Proposition Eoxia :
-https://www.eoxia.com/comparaison-doutils-pour-creer-un-onepage-html/
+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
+Proposition de travailler sur 2 axes :
-axe Expert IHM
+* 1 axe Expert IHM
-axe de nettoyage, preparation du code permettant d'accueillir les évolutions à venir
+* 1 axe de nettoyage, préparation du code permettant d'accueillir les évolutions à venir
-Iouston : Intégration de composant natifs déjà pensé et stabilisé
+Échanges :
-Proposition d'intégration en natif d'autres framework
+Code 42 : Propose la possibilité d'utiliser des outils comme figma https://www.figma.com/
-Tailwind (https://tailwindcss.com/)
+Faire intervenir un spécialiste externe UI/UX afin d'attaquer le sujet par la fin
-Onsen.io https://onsen.io/
-Bootstrap https://getbootstrap.com/
+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/
-Bulma https://bulma.io/
+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
+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é.
-Illustration du passage a de nouvelles version php, l'évolution c'est fait petit à petit
 UI
-Code 42 :
+Code 42 : Intégration dans le Bulder des nouvelles fonctions d'IHM
-Intégration dans le Bulder des nouvelles fonctions d'IHM
 >> Nouveau GIFF à créer !
@@ Line 60: / Line 63: @@
 - L'ajout de classes CSS à Dolibarr:
          -> classes enfants class --subclass
-         -> Definition d'un id html avec les objets (class=thirdparty id=thirdparty-211)
+         -> 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érencer les pages d'edition, de création et de vue niveau de la fiche
+         - Différencier les pages d'édition, de création et de vue (MVC) au niveau de chaque fiche basée sur le CRUD
-        - 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
+         -> Avantage: + Rapide pour passer les mises à jour dans la version suivante Dolibarr
 - Navigation
-         - Menu: manque de structure pour savoir ou on est
+         - Menu: manque de structure pour savoir où on est
-         - Breadcrumb ? Fil d'arianne ? Ou je me situe par rapport ou j'etais avant. Usernav history
+         - 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 integration future
+- Faire les modifications dont on a besoin dans le module Builder pour intégration future
-- liste -> 1 identité
+- Liste -> 1 identité
-- Nomenclature /  Accessibilité (data-attribute)
+- Nomenclature / Accessibilité (data-attribute)
 - Fonction wrapper des listes
-===APPLICATIONS MOBILES===
+===Applications mobiles et Progressives Web Applications PWA === Réalisé par Eric (CAP-REL)
-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 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
-Besoin d'un service Worker -> https://developer.mozilla.org/fr/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Offline_Service_workers
+* Intégration à Module Builder.
-Intégration à Module Builder.
 Big Data Consulting (Anexys) : Réalisation d'une application hybride en React Native (déjà en PROD)
@@ Line 94: / Line 94: @@
 VOLD : Réalisation d'une application mobile en mode déconnecté
-PR
+Pull Request à lancer
 * Token utilisateur
@@ Line 101: / Line 101: @@
 * Exemple implémentation appli mobile
-Problématique iOS est contraint Apple Store
+Problématique IOS est contraint Apple Store
+* Obligation d'avoir 2 Iphones (1 test, 1 production)
-Obligation d'avoir 2 Iphone, 1 mac pour compiler avec les bonnes versions de logiciel
+* 1 mac pour compiler avec les bonnes versions de logiciel
+* Le risque de se voir retirer facilement son application du store
-PWA :
-Pas de restriction par rapport au pilotage du matériel du smartphone
+Il existe de nombreux avantages :
-Https requis
+* 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.
--> déjà fait: voir [[GIFF - Socle Technique Mobile]] reste à établir les participants, le budget, les délais & objectifs etc.
-===FACTURE X===
+===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 ?
@@ Line 122: / Line 123: @@
 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 ?
+Voir le groupe de travail https://fnfe-mpe.org/ et proposition que l'association Dolibarr y adhère ?
 Page des spécifications
@@ Line 132: / Line 133: @@
 ===DOLIBARR LTS===
-Retour expérience EASYA-SOLUTIONS
+Retours expériences 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.
+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.
@@ Line 141: / Line 142: @@
 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
+Objectifs :
-Accompagnement/Formation à la réalisation de PR
+* Inciter à la publication de FIX avec une équipe LTS
+* Accompagnement/Formation à la réalisation de PR
 Définition de la notion de LTS
@@ Line 148: / Line 150: @@
 *Rythme : Une LTS tous les 2 ans
 *Durée : 5 ans
-*Publication de release sur le dépôt principal Dolibarr
+*Publication de releases sur le dépôt principal Dolibarr
-**Note: Doliwamp, packages, sourceforge  : non maintenu par l'équipe LTS
+**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
@@ Line 158: / Line 160: @@
 Proposition de numérotation des versions LTS
-*Version majeure : inchangé
+*Version majeure : inchangée
 *Version intermédiaire : Tous les 6 mois incrément de +1
 *Version corrective si CVE ou bug fonctionnel grave
-Charte mainteneur ( à établir)
+Charte du mainteneur (à établir)
-Outils de maintenance associés aux versions LTS : upgrade du core automatique ?
+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
@@ Line 173: / Line 175: @@
 * 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
+* 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
+* v18.1.1....v18.1.x au gré des fix
 * 6 mois plus tard v18.3.0
 * etc.
@@ Line 183: / Line 185: @@
 [[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 backup d'un autre intégrateur
+Pour chaque branche,
+* 1 mainteneur principal porté par un intégrateur + padawn
+* 1 mainteneur en backup d'un autre intégrateur.

DevCamp Lyon 2023 hiver: Difference between revisions

DevCamp Lyon 2023 hiver (view source)

Revision as of 20:39, 20 November 2023

Navigation menu

Search