L'ensemble des clones est situé à l'origine sur l'axe X du graphique lorsqu'un fichier est réuploadé/supprimé
Message d' Aurélie CAILLAULT VENET qui vient d'avoir un bug d'affichage.
Je viens de chercher la source de l'erreur. Celle-ci semble être dû a des erreurs de calcul de d3js dans la position X sur l'axe des abscisses. Elle n'existe pas à partir des fichier vidjil, ni en local, ni sur le serveur lui-même, qu'importe la branche.
J'ai trouvé une méthode pour corriger le graph et voir apparaitre celui-ci, mais c'est pas possible de la donner à nos utilisateurs. Il faut faire un drag&drop d'un point et le mettre dans l'espace de rangement sur le côté. Ainsi, les dates sont recalculées et les samples retrouvent bien leurs position.
Pour ce qui est la source de l'erreur, je crois l'avoir trouvée aussi.
Il me semble que l'un des échantillion n'a pas de timestamps renseigné pour le run (valeur "deleted" dans le m.sample.timestamp).
Je ne sais pas d'où sort cette valeur. Elle ne sont présentent nul part dans le fichier vidjil. A la place on a les dates de création des fichiers sur le serveur. Elle est retournée par le serveur non ? Ceci expliquerait pourquoi à l'update de l'axe, qui ne fait lui pas appel au serveur, il retourne une valeur Nan pour ce point et passe outre.
Après, je suis incapable de savoir pourquoi côté serveur nous avons une données erroné qui est retournée. Quid si un utilisateurs rentre un champs au format date incorrect ? C'est verifié avant validation ? Il peut en laisser un non rempli ?
Sûrement lié à #1220 (closed) ?
Je retourne chercher du côté de server/web2py/applications/vidjil/controllers/default.py. Je pense que k'erreur vient de là.
En attendant, comme le process est déjà etabli, il faut certainement qu'Aurélie lance de nouveau l'analyse du run, et en modifie les champs de date. Cependant, a-t-elle encore la main pour modifier après coup les données d'un "run". En impersonnate, je ne le vois pas.