You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@amandine-sahl a remonté un problème de synchronisation des données qui semblait applicatif : #26
En fait celui-ci est du fait que la configuration centralisée n'avait pas été mise en place sur son serveur GeoNature.
En effet celle-ci est indiquée comme optionnelle dans la documentation.
Alors qu'en fait si la table gn_commons.t_mobile_apps n'est pas renseignée, la route api/gn_commons/t_mobile_apps renvoie une erreur 404 et cela fait planter la synchronisation des données.
De la même manière, si un fichier de configuration n'est pas disponible sur le serveur GeoNature, alors cette même route api/gn_commons/t_mobile_apps renvoie une internal error (500) et cela fait aussi planter la synchronisation des données.
Plusieurs possibilités :
Côté GeoNature, faire en sorte que la route ne soit pas en 404 ni 500 quand les infos ne sont pas renseignés
Imposer la centralisation
Faire en sorte que la synchro fonctionne même si la route de centralisation ne renvoie rien ou est en échec
Mettre un message plus clair quand la route ne fonctionne pas
Ajouter des tests et des vérifications des erreurs dans l'application Sync-mobile
Il me semble dommage d'imposer la configuration centralisée.
Ça peut être gênant d'imposer les mêmes paramètres à tous les utilisateurs d'une instance (chemin des fichiers carto, étendue spatiale...) dans des contextes associatifs par exemple.
Pour commencer :
Je vais essayer de revoir la documentation pour indiquer qu'il faut vérifier le contenu de la route de configuration centralisée
On va voir côté GeoNature si on peut éviter la 404 quand la table gn_commons.t_mobile_apps n'est pas renseignée
Mais il serait utile d'avoir des vérifications et un message au niveau de Sync-mobile quand elle rencontre un soucis avec la route.
Et dans un second temps, voir si on peut imaginer un fonctionnement opérationnel sans configuration centralisée.
The text was updated successfully, but these errors were encountered:
C'est pas idéal, mais pour commencer rapidement, j'ai fait un ajustement dans la doc indiquant que la conf centralisée n'est actuellement pas optionnelle mais nécessaire au fonctionnement de la synchronisation : PnX-SI/gn_mobile_occtax@4f0a00b
@amandine-sahl a remonté un problème de synchronisation des données qui semblait applicatif : #26
En fait celui-ci est du fait que la configuration centralisée n'avait pas été mise en place sur son serveur GeoNature.
En effet celle-ci est indiquée comme optionnelle dans la documentation.
Alors qu'en fait si la table
gn_commons.t_mobile_apps
n'est pas renseignée, la routeapi/gn_commons/t_mobile_apps
renvoie une erreur 404 et cela fait planter la synchronisation des données.De la même manière, si un fichier de configuration n'est pas disponible sur le serveur GeoNature, alors cette même route
api/gn_commons/t_mobile_apps
renvoie une internal error (500) et cela fait aussi planter la synchronisation des données.Plusieurs possibilités :
Il me semble dommage d'imposer la configuration centralisée.
Ça peut être gênant d'imposer les mêmes paramètres à tous les utilisateurs d'une instance (chemin des fichiers carto, étendue spatiale...) dans des contextes associatifs par exemple.
Pour commencer :
gn_commons.t_mobile_apps
n'est pas renseignéeMais il serait utile d'avoir des vérifications et un message au niveau de Sync-mobile quand elle rencontre un soucis avec la route.
Et dans un second temps, voir si on peut imaginer un fonctionnement opérationnel sans configuration centralisée.
The text was updated successfully, but these errors were encountered: