Relevé qui ne se synchronise pas

[gildeluermoz]

Version de l'application

Version d'Occtax-mobile affectée par le bug : 2.6.1
Version de GeoNature utilisée : 2.12.3

Terminal et Version Android

Marque et modèle du terminal : ?
Version d'Android : ?

Description du bug et comportement attendu

Un relevé comportant 146 taxons et encore visible sur occtax-mobille et ne se synchronise pas.
Les données sont absentes sur occtax web (vérifié).
La personne m'a envoyé le répertoire Android/data/fr.geonature.occtax2/ mais inputs est vide (pas de carte SD sur ce terminal)
Je ne comprends pas comment le terminal peut afficher qu'il reste un relevé à envoyer alors que le répertoire inputs est vide. Est-ce qu'il y aurait un moyen de récupérer ce relevé pour ne pas perdre les données d'observation qui ont de la valeur (bureau d'étude en environnement).
Merci

Logs

Lors de toutes les synchronisations, les logs indique
18:58:49.313 INFO: [fr.geonature.datasync.packageinfo.worker.CheckInputsToSynchronizeWorker] available inputs to synchronize: 0

[sgrimault]

Bonjour @gildeluermoz,

Depuis la version 2.6.x les relevés ne sont plus gérés directement sous forme de fichiers comme auparavant (où on trouvait l'ensemble des relevés, terminés ou non dans le répertoire /Android/data/fr.geonature.occtax2/inputs), mais stockés en "base".
Tant que le relevé est en cours, on n'a rien dans le répertoire /Android/data/fr.geonature.occtax2/inputs. Il faut donc aller au bout et marquer le relevé comme terminé et prêt à être synchronisé pour le voir apparaître dans ce répertoire.
Ensuite, ce serait de voir pourquoi la synchronisation de ce relevé ne semble pas aboutir et pour cela, il suffit de récupérer le contenu JSON de ce relevé, puis de refaire les appels à l'API de GeoNature comme suit :

• POST -> /api/occtax/OCCTAX/only/releve, pour créer le relevé et récupérer son identifiant
• POST -> /api/gn_commons/media, pour envoyer les photos prises
• POST -> /api/occtax/OCCTAX/releve/{id}/occurrence où {id} correspond au relevé précédemment créé et ce, pour chaque occurrence présente par taxon

[gildeluermoz]

Bonjour et merci Sébastien pour ces précisions.

Voici qq infos complémentaires :

• ce relevé fait partie d'une liste de relevés terminés et est le seul à ne pas s'être synchronisé.
• Lorsque l'utilisateur clique sur le relevé, cela fait planter l'application. Il ne peut donc pas l'ouvrir pour le terminer.

et pour cela, il suffit de récupérer le contenu JSON de ce relevé

Il n'y a pas de json dans le répertoire inputs. Est-ce que ce contenu peut-être en base ? Si oui, où le trouver. Dans la base /Android/data/fr.geonature.occtax2/databases/data.db, je ne vois aucune table correspondant au contenu d'une observation. Est-ce que les relevés se mettent dans une autre base et si oui, où la trouver ?

Merci beaucoup.

[sgrimault]

Lorsque l'utilisateur clique sur le relevé, cela fait planter l'application.

Ah oui d'accord, ça ne sens pas bon... :/ J'ai comme l'impression que le JSON du relevé n'est pas conforme (pas un JSON valide d'où le plantage...)
Tu aurais moyen de récupérer les logs de l'application, histoire de voir où ça coince ?

Les relevés ne sont pas stockés au même endroit que les données issues de GeoNature (/Android/data/fr.geonature.occtax2/databases/data.db). Si tu peux accéder à /data/data/fr.geonature.occtax2/shared_prefs/fr.geonature.occtax2_preferences.xml, tu devrais retrouver les clés commençant par key_preference_input_.

Tu me dis aussi que le relevé comporte 146 taxons ? Et combien de dénombrements/photos prises par taxon ? Beaucoup ?

[sgrimault]

Après si ce relevé est bien listé en page d'accueil, ça veut dire que le JSON du relevé reste correct (puisqu'il a pu être chargé), c'est ailleurs que ça coince.
Si tu peux attraper les logs, ce serait bien :)

[gildeluermoz]

Merci. Je consulte l'utilisateur et je reviens vers toi quand j'aurai ces infos.
L'utilisateur m'a transmis un zip du répertoire /Android/data/fr.geonature.occtax2 mais pas sur qu'il y ait les logs de quand le souci s'est produit. Il y a 11 fichiers de logs du 11 avril entre 15:25 et 18:13 et je n'ai pas l'impression qu'ils comportent d'info sur l'erreur. Je te fais passer ces logs en MP.