2
edits
Eric.seigne (talk | contribs) No edit summary Tag: 2017 source edit |
m (→Outils de travail :: lien vers le decidim) |
||
| Line 7: | Line 7: | ||
==Présentation du sujet pour ce GIFF :== | ==Présentation du sujet pour ce GIFF :== | ||
* Exposer les solutions techniques pour l'affichage de Dolibarr et les utilisations sur mobile. | *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 | *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" | *Documenter, partager et accompagner le développement sur mobile d'applications "pour dolibarr" | ||
==Outils de travail :== | ==Outils de travail :== | ||
| Line 16: | Line 16: | ||
Forum : [https://www.dolibarr.fr/forum/t/giff-socle-technique-mobile/43476 www.dolibarr.fr/forum/t/giff-socle-technique-mobile/43476] | Forum : [https://www.dolibarr.fr/forum/t/giff-socle-technique-mobile/43476 www.dolibarr.fr/forum/t/giff-socle-technique-mobile/43476] | ||
Decidim : https://decidim-dolibarr.informatique-libre.com/assemblies/assemblee-giff-socle-mobile | |||
Plateforme de financement : à venir | Plateforme de financement : à venir | ||
| Line 49: | Line 49: | ||
Sujet abordé lors du DevCamp de Lyon 2023, proposition de GIFF en 2 ou 3 étapes | Sujet abordé lors du DevCamp de Lyon 2023, proposition de GIFF en 2 ou 3 étapes | ||
===== Etape 0 "vocabulaire" ===== | =====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 | *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 ===== | =====Etape 1===== | ||
Ajouter dans le module Builder de dolibarr un onglet "PWA" / "je souhaite que mon module offre un accès via une PWA" | 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 | *génération automatique du manifest.json pour permettre d'"installer" la PWA sur le smartphone | ||
* intégration du service worker dans le coeur de dolibarr qui offre ce service aux modules dont l'option PWA est activée | *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 | ||
* 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 / ..." | *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. | 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 ===== | =====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. | 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: | 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 | *Soit un utilisateur "patron", "patron" a accès à tous les modules dolibarr | ||
* 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. | *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: | 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 | |||
*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 | |||
[[Category:Groupement d'Intérêt Fonctionnel]] | [[Category:Groupement d'Intérêt Fonctionnel]] | ||
edits