Gestion des horaires lors de la saisie

[DonovanMaillard]

L'application permet de stocker l'heure de saisie, contenue dans les champs date. Mais cette heure n'est pas renvoyée dans les champs hour_min hour_max d'occtax (t_releves_occtax).

Faut il permettre de saisir des heures sur le mobile, faut il pouvoir choisir d'utiliser ou non l'heure de début/ fin de la saisie ? Dans tous les cas la gestion actuelle n'est pas homogène entre le mobile et le web

[camillemonchicourt]

Oui on avait pris le partie d'alléger Occtax-mobile au niveau des champs par rapport à Occtax-web.
Notamment en se limitant à une date, pas plusieurs ni d'heure.

On peut les ajouter si besoin, quitte à les masquer par défaut.

[DonovanMaillard]

Je sais pas s'il est necessaire d'ajouter les champs min/max etc, en revanche la manière dont est renvoyée l'heure me semble discutable :

• En web : soit on ne renseigne pas d'heure, le champs date contient alors JJ/MM/AAAA 00:00:00 et les champs hour_min hour_max sont NULL. Soit on saisit une heure, on a alors JJ/MM/AAAA 12:19:03 et les champs hour sont renseignés avec 12:19:03
• En mobile, le champs date comprend l'heure de saisie, qui n'est pas renvoyée dans les champs hour

Soit on renvoie systématiquement 0:00:00 comme heure sur la date_min et date_max de l'obs avec le mobile, soit on prévoit un paramètre coché par l'utilisateur "enregistrer les horaires de saisie" qui renvoie les heures dans les champs hour_min hour_max ? Ou on le fait par défaut...

Se pose ensuite la question de l'heure conservée : début de la saisie, fin de la saisie, ou hour_min et hour_max qui correspondent respectivement au début et à la finalisation de la saisie ? L'idée étant que l'utilisateur n'ait pas à les saisir à la main, en général sur le mobile on saisit ce qu'on voit en direct...

[camillemonchicourt]

En effet il y a un soucis vu ce que tu indiques.

Je pense qu'il ne faut pas le faire de manière transparente avec l'heure de saisie qui peut être différente de l'heure d'observation.

Si on veut ajouter les champs heures, alors il faut les afficher, les pré-remplir avec la date de saisie, pas besoin de case à cocher, mais permettre à l'utilisateur de les modifier.
Attention par contre, on doit garder la possibilité de les masquer, mais dans ce cas, cela risque de pousser l'heure de saisie de manière transparente et donc non souhaitable.

Je pense aussi que ce que l'on fait en web n'est pas idéal car on duplique une info.
Le champs DATE ne devrait stocker qu'une date et pas d'heure, et le champs heure l'heure si elle est renseignée.

[DonovanMaillard]

c'est ça, d'autant qu'on stocke l'heure + l'heure si renseigné, et minuit+NULL si non renseigné. Donc soit le champs date ne prend qu'une date, ça semblerait le mieux, soit on stocke date et heure dans un seul champs timestamp, comme aujourd'hui mais en supprimant les champs hour_min et hour_max

Le mieux serait peut-être en effet de pouvoir saisir les heures début/fin, en pré-remplissant par défaut avec l'heure de début de la saisie... Et de pouvoir masquer ces champs dans la conf (masqué par défaut si tu veux oui) auquel cas on renvoie NULL et non pas l'heure de saisie...

[DonovanMaillard]

Fera partie des corrections dans les versions 2.x à venir en 2022

[sgrimault]

Actuellement on a :

• date_min date UTC au format ISO 8601 (avec sa composante heure), renseigné par l’utilisateur de la création d'un relevé
• date_max qui prend la même valeur que l'attribut date_min
• Les attributs hour_min et hour_max ne sont pas renseignés
• L'utilisateur n'a pas la possibilité de saisir la composante heure du début du relevé (elle prend comme valeur l'heure actuelle du terminal, lors de la création du relevé)

Pour cette évolution on aura donc :

• Possibilité de saisir la date de fin par configuration (par défaut : non, et la date de fin prendra comme valeur la date de début renseigné dans le relevé par l'utilisateur)
• Possibilité de saisir en plus la composante heure sur les dates de début et de fin par configuration (par défaut : non, l'heure par défaut sera donc fixée à minuit)
• date_min date UTC au format ISO 8601 (avec sa composante heure, fixée à minuit si par configuration on ne souhaite pas la composante heure)
• date_max date UTC au format ISO 8601 (avec sa composante heure, fixée à minuit si par configuration on ne souhaite pas la composante heure)
• hour_min composante heure de l'attribut date_min au format ISO 8601, fixée à null si par configuration on ne souhaite pas la composante heure
• hour_max composante heure de l'attribut date_max au format ISO 8601, fixée à null si par configuration on ne souhaite pas la composante heure

Dites moi si c'est correct pour vous :)

Je serai d'avis de supprimer les attributs hour_min et hour_max coté GeoNature et d'uniformiser les dates en ne gardant que les attributs date_min et date_max au format ISO 8601 avec la composante heure.

[DonovanMaillard]

Merci Sébastien,

Seule remarque, si on active par configuration la saisie des horaires il serait bien que par defaut, heure min = heure max = par defaut l'heure de création du relevé, modifiable par l'utilisateur.

Il y a un ticket en cours pour uniformiser les dates et heures. Je ne sais pas encore s'il faut mettre des chamos date + des champs heures ou s'il faut seulement des champs timestamp (@camillemonchicourt ?). Cest vrai que pour les contraintes (min avant max) il serait plus simple d'avoir un seul champs...

[JeromeMaruejouls]

Seule remarque, si on active par configuration la saisie des horaires il serait bien que par défaut, heure min = heure max = par défaut l'heure de création du relevé, modifiable par l'utilisateur.

Entièrement d'accord avec la remarque de @DonovanMaillard . Occtax Mobile est fait pour saisir principalement des observations en direct et l'heure du début de saisie doit correspondre la plupart du temps à l'heure de l'observation.

[sgrimault]

C'est déjà le cas (mais je ne l'ai pas reprécisé), l'heure par défaut est bien celle au moment où l'utilisateur créé son relevé.
Dernière petite question/remarque : actuellement on ne peut pas saisir une date de début du relevé dans le futur, je suppose que ce sera le cas aussi pour la date de fin de relevé ?

[DonovanMaillard]

Pour la date de fin, je pense qu'on peut ne pas mettre cette contrainte. Si un observateur prévoit de passer une nuit à un endroit, il est plus pertinent qu'il puisse saisir dès le début sa date de fin au lendemain matin par exemple s'il le souhaite. On risque en effet de commencer la saisie au début du relevé, et donc avant la date ou l'heure de fin.

L'autre option serait de définir la date et l'heure de fin de relevé à la fin de la saisie, mais je pense qu'on compliquerait les choses en revenant à l'étape du relevé à la fin, et que ca pénalisera les 95% de saisies où tout se passe sur une seule date.

C'est vrai qu'il y a un sujet sur l'ergonomie sur ce point... Coté web la date de fin ne peut pas etre future. Coté mobile, on doit définir une heure de fin lors du début du relevé, ce qui est discutable. mais revenir sur ces infos en fin de saisie est assez discutable aussi dans bien des cas. Actuellement il faudrait donc faire sa saisie, ne pas la terminer, aller modifier le relevé pour mettre à jour les dates et heures de fin, puis aller terminer sa saisie. Déjà quand on pourra modifier les relevés terminés jusqu'à ce qu'ils soient synchronisés, on y verra plus clair car tout relevé terminé pourra être modifié pour mettre à jour les dates et heures de fin de relevés...

[DonovanMaillard]

Fait dans la 2.2 à paraitre

[camillemonchicourt]

2 paramètres ont ainsi été rajoutés dans la 2.2.0 (à venir). Un pour activer la saisie de la date de fin, un pour activer la saisie des heures. Ces paramètres sont à False par défaut. Leur fonctionnement a été ajouté à la documentation : https://github.com/PnX-SI/gn_mobile_occtax/tree/develop#input-settings

En n'activant pas ces 2 paramètres, la date de fin poussée au niveau du relevé est égale à la date de fin. Et les heures de début et de fin sont laissées à null.

[DonovanMaillard]

2.2 publiée avec cette fonctionnalité :)