MEG - Fluidifier le workflow de création/publication d’applications Mviewer sur GeoBretagne

[Gaetanbrl]

Issue développée dans le cadre d'une prestation JDev / Megalis Bretagne / GeoBretagne

Histoire

En tant que utilisateur du mviewerstudio sur la plateforme GeoBretagne,
Je souhaite pouvoir disposer d'une interface simple
Pour pouvoir déployer facilement une application en développement (beta) sur l'environnement de production

Description complémentaire

(à compléter si nécessaire)

[Agath21]

Proposition d'interface et parcours utilisateur

CAS 1 : Création d’une nouvelle application + passage en production

1 – Lors de la création d’une nouvelle application, le statut « Brouillon » est le statut par défaut. Il est indiqué par un badge dans le bloc « Wizard » à côté du titre :

2 – Je réalise la configuration de ma nouvelle application

3 – Dans le module « Publication », je clique sur « Publier votre application » :

4 – Une nouvelle fenêtre s’ouvre indiquant que l’application est disponible en ligne avec un lien de partage et un lien pour intégrer sa carte en iframe.

NOTE :

• Tant que l’utilisateur n’aura pas publié son config.xml, l’application restera en statut « brouillon »
• Le parcours utilisateur est identique pour passer une application existante « brouillon » en mode « en ligne »

CAS 2 : Gestion d’une application publiée

1 – Au sein de la page d’accueil, j’ouvre un projet existant en cliquant sur « Ouvrir un projet » et je sélectionne mon application :

Le statut de l’application est « en ligne », l’application a donc été publiée auparavant.

Modification d’une application en ligne

3 – Je réalise mes modifications.

4 – Pour publier mes modifications sur l’application en ligne, je dois cliquer sur publier les modifications :

Conception technique

Conception à revoir / valider dans le point du 08/03/2023 et selon le cotech du 06/03/2023 (voir CR)

• On crée et modifie mon_application.xml dans le studio avec le statut "brouillon"
• Quand on publie une application, on copie le xml à l'instant T dans prod/ (voir écran ci-dessus CAS 1)
• Dès publication d'une app, on ajoute un paramètre dans le XML indiquant que l'app est publiée
• L'application passe alors sous le statut "en ligne"
• Les modifications sont ensuite réalisée dans le studio et et exclusivement dans le dossier beta/ avec le statut "En ligne" (capté à l'aide du nouveau paramètre) (voir écran ci-dessus CAS 2)
• Ces modifications ne sont donc pas automatiquement publiées, il est nécessaire d'appuyer sur "publier mes modifications" pour réaliser une nouveau copier/coller dans prod/mon_application.xml.
• On peut donc réaliser une évolution de son app à différent moment sans perturber l'application en prod et utiliser la gestion des versions.

Questions :

• Peut-on dépublier une application ? et donc passer de "en ligne" à "brouillon"
• Mode multi-édition ? C'est le cas avec en ANONYMOUS, les cartes sont visibles, éditables par tous.

[Agath21]

Peut-on dépublier une application ? et donc passer de "en ligne" à "brouillon"

Ok pour ajouter un bouton "dépublier"

Proposition d'interface :

Accès en mode avancée > "Options" > "Dépublier une application"

[Gaetanbrl]

Validé dans le point du 08/03/2023

• On crée et modifie mon_application.xml dans le studio avec le statut "brouillon"
• Quand on publie une application, on copie le xml à l'instant T dans publiée/ (voir écran ci-dessus CAS 1)
• Dès publication d'une app, on ajoute une information dans une balise dédiée dans le XML qui indique que l'app est publiée
• L'application passe alors sous le statut "Publié"
• Les modifications sont ensuite réalisée dans le studio et et exclusivement dans le dossier beta/ avec le statut "Publié" (capté à l'aide du nouveau paramètre) (voir écran ci-dessus CAS 2)
• Ces modifications ne sont donc pas automatiquement publiées, il est nécessaire d'appuyer sur "mettre en ligne mes modifications" pour réaliser une nouveau copier/coller dans /publish/mon_application.xml.
• On peut donc réaliser une évolution de son app à différent moment sans perturber l'application en prod et utiliser la gestion des versions.
• Le bouton "ouvrir dans studio" n'est visible que pour les applications créent via mviewerstudio. Ce point nécessite une évolution dans mviewer pour gérer l'affichage du bouton selon le XML lu.
• Lors du clic sur le bouton "ouvrir dans studio", il est prévu d'ouvrir mviewerstudio sur la version du XML telle qu'elle est disponible avec ses dernières modifications dans le répertoire beta/ et non sur l'état du XML visible dans le répertoire /publish
• Depuis studio, il est possible d'ajouter un bouton "dépublier" pour une application qui est disponible dans le répertoire /publish

[spelhate]

Après échanges avec @lecault , voici ce qui est souhaité

La publication d'une application en mode déconnecté :

• IHM demande le nom technique de l'application ex: mon_application
• Studio créé un dossier mon_application dans un dossier public avec le config.xml et toutes les ressources nécessaires
• ce qui donnerait une URL du type : mviewer?config=/public/mon_application/config.xml

Si une application du même nom existe déjà, l'interface propose de la renommer.

La publication d'une application en mode connecté :

• IHM demande le nom technique de l'application ex: mon_application
• L'application créé un dossier mon_application dans un dossier monorganisme avec le config.xml et toutes les ressources nécessaires
• ce qui donnerait une URL du type : mviewer?config=/prod/monorganisme/mon_application/config.xml (affichage dans la fenêtre publié avec succès proposée par @Agath21 )

Si une application du même nom existe déjà, l'interface propose de la renommer.
monorganisme = nom court (Georchestra) ou nom. Dans les deux cas il faudra simplifier le nom pour enlever les caractères spéciaux.

Visibilité des application publiées en prod

Dans ouvrir un projet existant, mise en évidence des applications en prod avec affichage de l'url de publication.

[Gaetanbrl]

Les spécifications supplémentaires et détaillées étant survenus il y a 2 jours (voir dernier commentaire de @spelhate), le code actuel commencé bien avant ne prévoit pas l'organisation par répertoire pour les éléments publiés mais juste une dépose du XML dans un répertoire de publication. Cette logique se basée sur les derniers échanges et les maquettes / schéma échangés plus haut en COTECH et dans cette issue.

Ces nouvelles spécifications seront donc prises en compte à mon retour le 27/03/2023.

[Gaetanbrl]

Installation avant commentaire de détail des besoins du 14/03/2023 pour publication du XML dans un répertoire de publication (sans sous dossier)

Installation pour un environnement de production

Pour ajouter un répertoire publié par Apache :

1. Créer le répertoire de publication (ici on va utiliser /var/www/mviewer/apps/public) avec les bons droits (e.g www-data)
2. Ouvrir le fichier /etc/systemctl/system/mviewerstudio.service
3. Ajouter la variable d'environnement gunicorn MVIEWERSTUDIO_PUBLISH_PATH pour avoir au final ces 2 variables :

Environment="EXPORT_CONF_FOLDER=/var/www/mviewer/apps/store/"
Environment="MVIEWERSTUDIO_PUBLISH_PATH=/var/www/mviewer/apps/public/"

4. Sauvegarder et relancer le serveur

5. Modifier la configuration du frontend

• Dans srv/python/mviewerstudio_backend/static/config.json

Il faut rajouter ce paramètre pour disposer du lien de partage final (voir input ci-dessous)

"mviewer_publish": "https://ma-production/mviewer/?config=",
`

Installation pour un environnement de développement

Ne pas suivre les explications précédentes et passer directement à la partie configuration.

• Dans srv/python/mviewerstudio_backend/static/config.json

Ajouter :

"mviewer_publish": "http://localhost:5051/?config=",

• Dans /srv/python/mviewerstudio_backend/settings.py

Il faut rajouter l'emplacement du répertoire de publication via ce paramètre en s'assurant que flask peut écrire dans ce répertoire avec les bons droits :

MVIEWERSTUDIO_PUBLISH_PATH = os.getenv("MVIEWERSTUDIO_PUBLISH_PATH", "public")

... ou comme variable d'environnement :

export MVIEWERSTUDIO_PUBLISH_PATH = '/mviewerstudio_backend/public'

[lecault]

Scénario proposé :

• Après clic sur publication, on arrive sur une modale qui propose un mon_unique_app par défaut que l'utilisateur peut modifier (pas de caractères spéciaux, ni d'espaces).
• Clic sur Publier publie l'application et renvoie sur la page actuelle avec les liens de partage
• Dans cette page, le bouton retour renvoi à la page de saisie de mon_unique_app

Règles du mon_unique_app par defaut : les mêmes que pour le XML à savoir :

• Remplacer les espaces par underscores
• Mettre tout en minuscule
• Remplacer les accents par les lettres sans accents (idem pour ç)
• Remplacer les autres caractères spéciaux (&, %) par un undescore
• Limiter à 20 caractères

[Gaetanbrl]

@lecault @spelhate @Agath21 , après réflexion, est-ce qu'il ne serait pas aussi intéressant de pouvoir saisir un nom unique dès la création de l'application et non pas lors de la publication ?

Le parcours utilisateurs serait donc le suivant :

1. Clic sur "Créer"
2. Modifier la configuration
3. Saisir un nom unique qui ne sera pas basé sur le titre dans un input ou dans une modal lors du 1er clic sur "Enregistrer"
4. Cliquer sur "Publier" => Fonctionnement actuel, pas de changement de nom possible

Avec des noms homogène entre le mode brouillon et publié, ce parcours permet de faciliter l'identification d'une application entre le répertoire brouillon et le répertoire publication car le nom est commun.
Sinon, il faut un mapping (complexité +) pour savoir quel brouillon correspond à quelle application publiée étant donné que le nom est différent.

Depuis l'IHM d'édition, cela permet en autre de télécharger l'application avec un nom "final" qui est également le nom de l'application publiée.

Le téléchargement impose également de prévoir une mécanique de création de ZIP dans le backend afin de récupérer un XML et l'ensemble de ses ressources (customX, mst...). Ce point n'avait pas été soulevé jusque là.

[Gaetanbrl]

Sinon, il faut un mapping (complexité +) pour savoir quel brouillon correspond à quelle application publiée étant donné que le nom est différent.

Pour ce point, je vois sinon que DublinCore permet d'ajouter une relation dans les meta.

On peut alors faire un mapping facilement sans avoir de code complexe dans le XML directement via une balise Relation :

https://www.dublincore.org/specifications/dublin-core/dcmi-terms/elements11/relation/

Ainsi, lors de la suppression d'un XML ou de sa re publication, nous pourrons lire la meta Relation et identifier facilement le bon XML dans le répertoire de publication.

[lecault]

Quand tu dis nom on est bien d'accord qu'on parle du nom du dossier. Je trouve l'idée intéressante de saisir ce nom au premier enregistrement. Il faut que studio propose un nom par défaut
Question : est ce que le dossier physique de stockage de brouillon porte le même nom ? Si oui, on pourrait avoir des soucis car ce dossier contient toutes les apps de tous les partenaires (contrairement à la publication en prod par organisme).

Par contre, le fait de ne pas pouvoir le modifier est un soucis : on ne sait pas toujours la finalité de l'app à la création. A minima au passage en production. Donc on échappera pas à un mapping.

[Gaetanbrl]

Quand tu dis nom on est bien d'accord qu'on parle du nom du dossier
est ce que le dossier physique de stockage de brouillon porte le même nom ?

Oui - le nom c'est le nom de fichier et du dossier du même nom.

---

on pourrait avoir des soucis car ce dossier contient toutes les apps de tous les partenaires

Je ne suis pas certain de comprendre. A quel dossier fais-tu référence ?

Dans le répertoire de publication (ce que tu appels la prod) ou dans le répertoire brouillon on va avoir une séparation par organisme. C'est d'ailleurs ce que j'ai déjà réalisé dans la branche jdev-org/issue-161.

Ce point correspond à votre demande : Avoir une structure par organisation.

Ce n'est pas cela ?

---

Il faut que studio propose un nom par défaut

Cette règle n'était pas spécifiée. Comment doit être fourni le nom par défaut ? Sur quelles règles (e.g à partir du titre comme fait jusque là) ?

[lecault]

Je ne suis pas certain de comprendre. A quel dossier fais-tu référence ?

Au dossier dans store : https://gis.jdev.fr/mviewer/?config=apps/store/383b7e1e9136/VN.xml
Mais la présence de dossier par organisme résous le truc (il me semblait bien qu'il y avait ça pour le mode brouillon mais je ne savais plus où.
Et oui on est d'accord là dessus.

• Après clic sur publication, on arrive sur une modale qui propose un mon_unique_app par défaut que l'utilisateur peut modifier (pas de caractères spéciaux, ni d'espaces).

C'est ici que je faisais référence au nom par défaut.

Sur quelles règles (e.g à partir du titre comme fait jusque là) ?

Et oui à partir du titre en corrigeant les caractères spéciaux.
Quelques exemples de titre avec leur correspondance en nom d'appli :

• Voies navigables => voies_navigables
• Filière de maçonnerie => filiere_de_maconnerie
• Appli 100% => appli_100

[Gaetanbrl]

Merci Loïc, je vais donc garder ce fonctionnement conformément au CR du COTECH :

• 1 organisme = 1 répertoire que ce soit en brouillon ou en publication
• 1 nom = nom du répertoire des ressources du XML
• 1 nom = nom du XML (identique au nom du répertoire des ressources)
• Demande de personnalisation du nom à la publication ==> Utilisation de la balise <dc:relation> pour lier le brouillon et la publication
• Lors de la publication (clic sur "Publication") :

Par défaut on propose titre normalisé (voir règles)
L'utilisateur peut alors modifier le nom.

Ce nom sera réutilisé tel que pour un nom "Voies navigables" on obtiendra dans le répertoire de publication (et uniquement dans celui-ci) un XML voies_navigables.xml et un répertoire organisme/voies_navigables au même niveau que le XML dans le répertoire de l'organisme d'appartenance.

Je verrai ensuite selon le temps, si l'utilisateur peut adapter le nom dès la création.

[spelhate]

Le téléchargement impose également de prévoir une mécanique de création de ZIP dans le backend afin de récupérer un XML et l'ensemble de ses ressources (customX, mst...). Ce point n'avait pas été soulevé jusque là.
👍 +1

[spelhate]

Merci Loïc, je vais donc garder ce fonctionnement conformément au CR du COTECH :

* 1 organisme = 1 répertoire que ce soit en brouillon ou en publication

* 1 nom = nom du répertoire des ressources du XML

* 1 nom = nom du XML (identique au nom du répertoire des ressources)

* Demande de personnalisation du nom à la publication ==> Utilisation de la balise `<dc:relation>` pour lier le brouillon et la publication

* Lors de la publication (clic sur "Publication") :
  Par défaut on propose titre normalisé ([voir règles](https://github.com/mviewer/mviewerstudio/issues/161#issuecomment-1483047482))
  L'utilisateur peut alors modifier le nom.

Ce nom sera réutilisé tel que pour un nom "Voies navigables" on obtiendra dans le répertoire de publication (et uniquement dans celui-ci) un XML voies_navigables.xml et un répertoire organisme/voies_navigables au même niveau que le XML dans le répertoire de l'organisme d'appartenance.

Je verrai ensuite selon le temps, si l'utilisateur peut adapter le nom dès la création.

Ok pour moi

[lecault]

Merci Loïc, je vais donc garder ce fonctionnement conformément au CR du COTECH :

• 1 organisme = 1 répertoire que ce soit en brouillon ou en publication
• 1 nom = nom du répertoire des ressources du XML
• 1 nom = nom du XML (identique au nom du répertoire des ressources)
• Demande de personnalisation du nom à la publication ==> Utilisation de la balise <dc:relation> pour lier le brouillon et la publication
• Lors de la publication (clic sur "Publication") :
  Par défaut on propose titre normalisé (voir règles)
  L'utilisateur peut alors modifier le nom.

Ce nom sera réutilisé tel que pour un nom "Voies navigables" on obtiendra dans le répertoire de publication (et uniquement dans celui-ci) un XML voies_navigables.xml et un répertoire organisme/voies_navigables au même niveau que le XML dans le répertoire de l'organisme d'appartenance.

Je verrai ensuite selon le temps, si l'utilisateur peut adapter le nom dès la création.

ok pour moi.

Question : si on clique sur enregistrer et que le nom existe déjà quel comportement ? On peut la renommer depuis le bouton enregistrer ?

[Gaetanbrl]

Question : si on clique sur enregistrer et que le nom existe déjà quel comportement ? On peut la renommer depuis le bouton enregistrer ?

Voici le scénario que vous avez convenu avec @Agath21 pour ce cas :

1. Saisie du nom
2. Clic sur "Publier"
3. Alerte "Cette application existe déjà"
   4.a. Souhaitez-vous l'écraser ? => supprime et remplace l'application existante
   4.b Conserver et renommer l'application à publier

Est-ce que cela convient @lecault ?

[lecault]

Question : si on clique sur enregistrer et que le nom existe déjà quel comportement ? On peut la renommer depuis le bouton enregistrer ?

Voici le scénario que vous avez convenu avec @Agath21 pour ce cas :

1. Saisie du nom
2. Clic sur "Publier"
3. Alerte "Cette application existe déjà"
   4.a. Souhaitez-vous l'écraser ? => supprime et remplace l'application existante
   4.b Conserver et renommer l'application à publier

Est-ce que cela convient @lecault ?

ok pour nous

[spelhate]

La branche 161 ne semble pas fonctionnelle :

[Gaetanbrl]

le apps/config.json est bon ?

A voir dans VSCode ou tester le fichier avec :

https://jsonformatter.curiousconcept.com/

[lecault]

Ah bien vu !
Le traitement de vos 2 cas me va.

[spelhate]

apps/config.json

J'ai des difficulté pour faire fonctionner la branche issue-161. le checkout + git pull depuis develop-meg génère des conflits de merge :

[spelhate]

Ah bien vu !
Le traitement de vos 2 cas me va.

Même chose pour moi

[spelhate]

Retour test branche issue-161 : en mode déconnecté, le dossier de publication est doublé :

[spelhate]

lien de partage incomplet

[Gaetanbrl]

@spelhate je viens de t'envoyer un message via Element.
En effet, c'est l'URL complète utilisée par Python pour coller le fichier.

Pour avoir une URL accessible, il faut être certain que l'URL pointe vers un répertoire de publication dans mviewer/apps comme c'est le cas pour le mviewer/apps/store.

Pour un répertoire /public, on aurait alors donc mviewer/apps/store.

Est-ce que vous pouvez me confirmer que le répertoire de publication est bien dans le répertoire apps de mviewer pour qu'on puisse bien créé une URL accessible de l'extérieur ? @spelhate @lecault

[Gaetanbrl]

@spelhate

Retour test branche issue-161 : en mode déconnecté, le dossier de publication est doublé :

J'obtiens bien un répertoire doublé :

http://127.0.0.1:5051/?config=public/public/lycees.xml

Mais il s'explique par le fait que j'ai un répertoire de publication qui s'appel "public" et que mon organisme par défaut (en anonyme) s'appel public également.

On a donc le schéma :

publication_dir/org_name/file.xml

... qui retourne :

http://127.0.0.1:5051/?config=apps/store/public/public/lycees.xml

---

Je vois aussi qu'il te manque un / en séparateur. Je pense que je viens de corriger le problème.
A voir lors de la mise à jour de ta branche.

[spelhate]

our avoir une URL accessible, il faut être certain que l'URL pointe vers un répertoire de publication dans mviewer/apps comme c'est le cas pour le mviewer/apps/store.

Pourquoi cette contrainte ?
ça doit marcher même si le store est extérieur à mviewer. Exemple /applications/store

[Gaetanbrl]

Si le lien est incomplet, c'est qu'il manque une partie du lien dans la configuration.
Pour ce lien, on utilise les paramètres :

• config.json > mviewer_publish (qui devrait s'appeler autrement)

https://github.com/jdev-org/mviewerstudio/blob/issue-161/lib/mv.js#L2011

• setting.py > CONF_PATH_FROM_MVIEWER

ça doit marcher même si le store est extérieur à mviewer. Exemple /applications/store

Je viens de rajouter la prise en compte de ce paramètre mais il est donc faux.

https://github.com/jdev-org/mviewerstudio/blob/522a79a7c5f43c5d0cdbedcab12d5f98844c1af4/srv/python/mviewerstudio_backend/route.py#L206

[spelhate]

Je précise que je n'ai rien configuré avant de tester cette branche. Il va falloir que je commence par ça.

[Gaetanbrl]

Il va falloir que je commence par ça.

Ah ! Je roll back ma dernière modif que j'ai rajoutée en pensant que tu voulais que ca pointe vers un repo mviewer... je dois apporter un correctif.

Sinon il faut :

1. adapter la config (notamment config.json > mviewer_publish)

A noter que le nom de paramètre mviewer_publish est en train de devenir publish_folder !

2. Rajouter votre règle apache

... afin de réorienter vers le bon répertoire pour que la valeur publish_folder dans l'URL soit bien détectée et réorientée vers MVIEWERSTUDIO_PUBLISH_PATH

3. Adapter dans settings.py le répertoire de publication

On envoi au front un chemin type publication_dir/org/file.xml :

public/public/lycees.xml

---

Parcours :

1. utilisateur publie une application
2. utilisateur consulte l'URL fourni par la modal
3. utilisateur copie https://mes-cartes.fr/public/jdev/commerces.xml
4. utilisateur ouvre https://mes-cartes.fr/public/jdev/commerces.xml
5. apache détecte mes-cartes.fr (c'est le publish_folder dans config.json)
6. apache retourne la carte présente dans le répertoire de publication (c'est MVIEWERSTUDIO_PUBLISH_PATH dans settings.py)

---

Sinon la doc a été mise à jour mais dans cette branche pour cette config ;)

[Gaetanbrl]

A fermer @lecault @spelhate ?

[spelhate]

Ok. je ferme