GIFF - Socle Technique Mobile

Rappel, un GIFF ...

GIFF : Groupement d'intérêt financier et fonctionnel

Plus de détails sur la page dédiée: Groupement d'Intérêt Fonctionnel et Financier - GIFF

Présentation du sujet pour ce GIFF :

• Exposer les solutions techniques pour l'affichage de Dolibarr et les utilisations sur mobile.
• Ajouter dans le coeur de Dolibarr le nécessaire pour que des développeurs tiers puissent proposer des applications sur mobile directement interfacées sur Dolibarr
• Documenter, partager et accompagner le développement sur mobile d'applications "pour dolibarr"

Outils de travail :

Forum : www.dolibarr.fr/forum/t/giff-socle-technique-mobile/43476

Wiki : à venir

Plateforme de financement : à venir

Intervenants et rôles : CAP-REL, Evarisk, Inovéa Conseil, TimGroup , Tiaris, Easya Solutions

Choix du porteur de projet pour les outils : à venir

Channel sur Discord : à venir

Problématique détaillée :

Nous avons de plus en plus de besoins liés aux périphériques mobiles (smartphone mais pas que) pour lesquels il semble plus efficace de proposer des PWA (Progressive Web Apps) plutôt que des applications natives (android + ios).

CAP-REL a présenté une implémentation "dolibarr/PWA" de DoliSCAN sous le nom de ScanExpenses en utilisant la même pile technique que DoliSCAN : onsenui + jquery, voir la présentation sur le forum: https://www.dolibarr.fr/forum/t/notes-de-frais-vous-connaissez-doliscan-et-scaninvoices-vous-allez-peut-etre-aimer-scanexpenses/40165 puis SmartDLC, SmartInterventions et SmartLivraisons

Lors du devcamp Bordeaux 2023 Vincent Maury présente une solution technique qui s'appuie sur boostrap + (...) voir plus de détails sur le forum https://www.dolibarr.fr/forum/t/module-poc-webapp-responsive-incluannt-bootstrap-qrcode-scanner-photo-draw/42242

Inovéa Conseil propose un outil d'interventions techniques utilisable 100% sur smartphone et développe donc une expertise / besoin terrain sur ce sujet.

Tiaris a développé un portail spécifique 'commerciaux' pour tablette

Ces quatre solutions nous donnent envie de creuser quelques pistes "cas concrêts" pour faire un choix structurant pour proposer ensuite une pile unie validée par le projet Dolibarr permettant ainsi dans quelques temps à tout développeur dolibarr qui souhaiterait développer une PWA de ne pas avoir à réinventer la roue ..

Easya Solution a développé des portails web et application "Gros boutons" sur la base de boostrap

Historique :

Création du GIFF lors du DevCamp de Bordeaux 2023

Sujet abordé lors du DevCamp de Lyon 2023, proposition de GIFF en 2 ou 3 étapes

Etape 0 "vocabulaire"

• PWA = progressive web app, en bref un accès un peu spécial à une arborescence de votre site web qui se présentera sous la forme d'une application sur votre smartphone. -> https://fr.wikipedia.org/wiki/Progressive_web_app
• .../...

Etape 1

Ajouter dans le module Builder de dolibarr un onglet "PWA" / "je souhaite que mon module offre un accès via une PWA"

• génération automatique du manifest.json pour permettre d'"installer" la PWA sur le smartphone
• génération des pages minimales "PWA" comme le module builder génère actuellement des pages de base "backend dolibarr natif" pour le module et tout objet généré par le module builder
• intégration du service worker dans le coeur de dolibarr qui offre ce service aux modules dont l'option PWA est activée
• apporte un ensemble "css/js" cohérent pour que toute application PWA générée par le module builder puisse partager la même "pile", le choix de la pile en question fait partie de ce GIFF ce choix sera automatiquement intégré aux modules mais pourra être modifié/désactivé/remplacé par une autre pile si le développeur du module le souhaite ... mais nous pensons qu'il serait astucieux de partager cette pile pour que toute application "PWA Dolibarr" ait la même "ergonomie / apparence / ..."

Utiliser l'API actuelle de dolibarr (voir étape 2), les modules générés par le module builder peuvent enrichir l'api pour répondre aux besoins et la création d'un utilisateur dédié permet de restreindre les accès à la partie de l'api visée par l'application. Cette solution est transitoire et permet d'avancer d'une étape.

Etape 2

Modifier la gestion de l'accès à l'API dolibarr. Actuellement un utilisateur dispose d'une clé d'API. L'objectif visé est de pouvoir gérer plusieurs clés d'API par utilisateur. Chaque clé pouvant avoir un accès restreint à un sous ensemble de l'API.

Exemple:

• Soit un utilisateur "patron", "patron" a accès à tous les modules dolibarr
• La clé d'API principale de patron : accès à toute l'API
• Patron utilise une application de gestion de notes de frais, lorsqu'il s'authentifie sur l'application notes de frais la clé d'API utilisée n'a accès qu'au sous ensemble "notes de frais" de dolibarr. Ainsi lorsque patron change de téléphone, l'ancienne clé d'API est désactivée et une nouvelle clé d'API est générée. Cloisonnement des périmètres. Une clé peut avoir un cycle de vie particulier distinct du cycle de vie de l'utilisateur.

Illustration:

• Lorsque vous connectez une application à nextcloud, lors de la 1ere authentification l'application et le serveur dialoguent et une fenêtre permet à l'utilisateur de choisir/confirmer les données auxquelles l'application aura accès