Closed lepontois closed 8 months ago
J'ai mis le doigt sur le problème et j'ai trouvé la solution adaptée.
ça se passe en ligne 22 du formValidators : https://github.com/PnX-SI/GeoNature-citizen/blob/master/frontend/src/app/programs/observations/form/formValidators.ts L'expression régulière permettant de contrôler la validité des coordonées n'accepte que des valeurs positive. Mes tests étant de l'autre côté du méridien, il me retournait toujours false.
Voici ma proposition de correction (c'est celle que j'applique sur mon instance) :
[...]
const validGeometry = /Point\([-]?\d{1,3}(|\.\d{1,7}),(|\s)[-]?\d{1,3}(|\.\d{1,7})\)$/.test(
[...]
Merci de reporter ce correctif dans les sources (je ne suis pas relié au git)
Concernant l'installation packagée, on a identifié plusieurs soucis dans la 0.99.3, et ils ont été réglé dans la branche "develop" avec notamment de nombreuses mises à jour de dépendances. Voir le ticket sur le sujet. En attente de la release de la 0.99.4 qui inclut ces corrections.
Merci pour ton retour détaillé d'installation.
Le ticket d'il y a quelques jours sur les problèmes de version des dépendances que tu as rencontré : https://github.com/PnX-SI/GeoNature-citizen/issues/271
Concernant les coordonnées négatives, en effet ça a été remonté dans un ticket il y a quelques semaines, avec la correction du code à appliquer (https://github.com/PnX-SI/GeoNature-citizen/issues/261).
Merci et bon weekend.
Bonjour,
J'ai rencontré le même problème que toi @lepontois sur la route get_observations de citizen (branche 0.99.4-dev) sur debian 10. Merci pour ton script sql qui m'a bien aidé sur le moment.
Pour tenter de corriger ce bug, je viens d'essayer de déplacer le bloc suivant : https://github.com/PnX-SI/GeoNature-citizen/blob/699067934ba5e700b5d47a3f77e99bc6c0354d0e/backend/server.py#L95-L97 Juste avant la ligne https://github.com/PnX-SI/GeoNature-citizen/blob/699067934ba5e700b5d47a3f77e99bc6c0354d0e/backend/server.py#L141 Exactement comme c'était fait sur le tag 0.99.1 : https://github.com/PnX-SI/GeoNature-citizen/blob/5caf4545ca6f188396bdc6cd6db9a1cf49def386/backend/server.py#L155-L160
Et cela semble résoudre le problème chez moi. Toutes les tables sont bien créées et je n'ai pas d'erreur lorsque j'accède à l'URL de citizen.
@camillemonchicourt, as-tu rencontré le même problème lors de tes tests ?
Je vais essayer de regarder quel commit a déplacé ce bloc de code. Je vous tiens au courant.
Cela semble être dû à ce commit : https://github.com/PnX-SI/GeoNature-citizen/commit/54a249021f293e988c3cdcf8967d8151ca969b50#diff-7aad1d8a7c12e554a56640e331270f5fc84e24f6f937b35b69eb83766b2318ed Mais il n'y a pas l'air d'y avoir plus d'explications.
A priori corrigé dans la version 1.0.0
Bonjour,
Il y a quelque temps j'avais réalisé une installation en locale de GN-Citizen pour évaluer son adéquation avec nos besoins.
Je passe à présent à une "vraie" installation et je tenais à vous partager ce retour d'expérience.
L'installation est réalisée sur un ubuntu server 18.04 à partir de la pre-release 0.99.3
J'ai suivi la doc d'installation manuelle (car l'automatique m'avait posé problème en locale) sans faire d'installation de taxhub vu qu'il est déjà en place sur un serveur GeoNature indépendant. J'ai tout de même intégré en base le schema taxonomie car même si GN-Citizen peut interoger un taxhub distant, j'ai cru comprendre qu'il avait tout de même besoin de ce schéma.
J'ai donc déroulé la précédure d'installation mais je rencontre un bug en fin de course lorsque j'exécute : sudo supervisorctl reload : cannot import name 'get_jwt' Pour résoudre ça, j'ai dû mettre à jour flask_jwt_extended :
pip install flask_jwt_extended --upgrade
J'ai également mis à jour flask_admin car j'ai eu une erreur similaire pour l'import de secure_filename :
pip install flask_admin --upgrade
A l'étape de création de la structure de la base de données
seules quelques tables ont été créés :
Le schéma gnc_core n'est donc pas complet et aucune table dans les schémas gnc_obstax et gnc_sites.
Grâce à ma précédente installation locale, j'ai pu reconstruire la base. (voir script sql à la fin de ce message)
A partir de ce point l'interface web est accessible (quelque souci avec iptables qui doit autoriser l'intégralité des OUTPUT : iptables -A OUTPUT -j ACCEPT)
Sauf que ! Et oui, ce n'est pas fini, et pour le coup, je suis à sec... Lorsque je suis sur le formulaire de saisie d'une observation, impossible de valider l'observation. Le bouton reste toujours "disable" malgré que les champs soient complétés. (si je retire disable via la console, le formulaire s'enregistre bien mais pas très commode :) ). Il semble donc qu'il y ait quelque chose dans le contrôle du formulaire qui bloque. C'était déjà le cas sur mon instance locale mais j'ai pas trop insisté.
Pour ceux qui souhaitent tester, le serveur n'étant pas encore associé à un nom de domaine, il vous faut ajouter dans votre fichier hosts l'entrée suivante :
188.165.58.13 obs-citoyenne.pyrenees-parcnational.fr
et du coup, vous aurez accès à cette instance de citizen par http://obs-citoyenne.pyrenees-parcnational.frEn espérant que vous aurez des éléments à m'apporter et que ce retour d'expérience pourra être utile à d'autres. Merci !
Annexe : Script sql permettant de reconstruire la base (ce script ajoute les tables manquantes uniquement)