vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2016-11-29T14:43:09+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/2008Redirection de / vers /browser en HTTPS2016-11-29T14:43:09+01:00Vidjil TeamRedirection de / vers /browser en HTTPSEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbEn allant sur https://dev.vidjil.org je ne suis pas redirigé vers le /browser, il faut le rentrer à la main dans l'URL.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2007Empêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espac...2020-01-08T17:39:47+01:00Vidjil TeamEmpêcher l'upload ou de lancer des jobs lorsqu'il ne reste plus assez d'espace disqueOn sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on...On sait où les séquences et les résultats sont stockés. Si on passe en dessous d'un seuil d'espace libre pour un de ces emplacements, il faut empêcher l'upload ou le run (c-à-d. avoir un test en plus dans VidjilAuth ?). De cette façon on ne se retrouve jamais avec un disque plein et pas avec des jobs en failed parce qu'il n'y a plus d'espace disque.
Par contre, prévoir de spammer les admins dès que la limite est atteinte pour qu'ils fassent quelque chose (en générant un ticket web2py ?)
***
C'est en prod. On a une limite en pourcentage qui se fixe dans defs.py. Actuellement réglé sur 1%. La limite est commune pour toutes les partitions mais la vérification est spécifique (donc il peut s'avérer que l'upload soit bloqué, mais pas les runs
***
Merci Ryan.
***
@RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2006ECMAScript v6 ? Version du DOM ?2022-06-10T12:00:56+02:00Vidjil TeamECMAScript v6 ? Version du DOM ?83a112a, Mikael:
segmenter.js: includes() method is a bit new
(…) It is part of the ECMAScript 2016 standard while indexOf is part of the
ECMAScript 5.1 standard (2011).
De la même manière que notre code C++ est du C++11 (et pa...83a112a, Mikael:
segmenter.js: includes() method is a bit new
(…) It is part of the ECMAScript 2016 standard while indexOf is part of the
ECMAScript 5.1 standard (2011).
De la même manière que notre code C++ est du C++11 (et pas du C++14), nous devrions décider quelle version d’ECMAScript nous utilisons.
Et peut-on le forcer dans les tests unitaires / fonctionnels ?
Cela nous aiderait peut-être à répondre à #1077.
***
Le phantomjs sur Jenkins n'étant pas très à jour, du javascript 2016 ne passera pas dessus (c'est ce qui m'est arrivé)
Mais ça ne répond pas vraiment aux questions…
***
@magiraud @RyanHerb @mikael-s @DuezWeb 2018.01https://gitlab.inria.fr/vidjil/vidjil/-/issues/2005Après un compare sample, le scatterplot n'est pas initialisé2017-05-22T15:26:06+02:00Vidjil TeamAprès un compare sample, le scatterplot n'est pas initialiséExemple ici : http://rbx.vidjil.org/browser/?custom=5611&custom=777&
Je n'ai que ? comme label du scatterplot. Il faut appuyer sur g pour que le scatterplot se mette en mode TRG.
***
@RyanHerb @Duez @magiraud Exemple ici : http://rbx.vidjil.org/browser/?custom=5611&custom=777&
Je n'ai que ? comme label du scatterplot. Il faut appuyer sur g pour que le scatterplot se mette en mode TRG.
***
@RyanHerb @Duez @magiraud Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2004igBlast ne fonctionne plus2016-11-29T14:43:07+01:00Vidjil TeamigBlast ne fonctionne plusAucun souci pour moi, sur ma machine ou sur rbx. Plus d'info ?
Pour info j'ai poussé hier une modif qui met IgBlast en HTTPS (car le NCBI passe en HTTPS). Serait-ce lié ?
***
Curieux. Hier cela m'était arrivé sous Safari. Ré-essayé à l'i...Aucun souci pour moi, sur ma machine ou sur rbx. Plus d'info ?
Pour info j'ai poussé hier une modif qui met IgBlast en HTTPS (car le NCBI passe en HTTPS). Serait-ce lié ?
***
Curieux. Hier cela m'était arrivé sous Safari. Ré-essayé à l'instant, sur rbx et depuis Firefox sans cache, et même error. Screenshot joint. Par contre, cela fonctionne sans soucis si je vais sur la page d'IgBlast et que je soumets des séquences.
Est-ce depuis l'université de Thessalonique serait blacklistée d'une certaine manière ? Ou est-ce ma machine qui est curieuse en ce moment ?
***
Tu sembles en HTTP, et donc ce que j'ai poussé hier soir (uniquement sur dev pour l'instant) devrait corriger ton problème (c'était un des tests fonctionnels cassés, d'ailleurs). Essaie avec le browser en local. Comme c'est une modif dans un fichier JS il faut éventuellement rafraichir ton cache.
En allant sur la page d'IgBlast la redirection vers HTTPS se fait bien (je ne sais pas pourquoi elle ne se fait pas avec la requête POST).
***
Oui, c'est cela, cela fonctionne ! Au temps pour moi, je n'avais pas vu ce coup d'HTTPS.
***
@magiraud @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2000Lorsque le run est mal renseigné, ne pas permettre la soumission du formulaire2017-07-05T09:15:55+02:00Vidjil TeamLorsque le run est mal renseigné, ne pas permettre la soumission du formulaireLors de l'ajout d'un fichier, si on ajoute un run qui n'existe pas, il est coloré en rouge mais on peut soumettre le formulaire, ce qui génère ensuite une boite de dialogue disant : « [object Object] error INTERNAL SERVER ERROR », ce qui...Lors de l'ajout d'un fichier, si on ajoute un run qui n'existe pas, il est coloré en rouge mais on peut soumettre le formulaire, ce qui génère ensuite une boite de dialogue disant : « [object Object] error INTERNAL SERVER ERROR », ce qui n'est pas très parlant.
J'imagine que du côté client il y a moyen de contrôler que les champs run et patient sont remplis avec des données correctes.
***
Hotfix prête, déployée sur dev.
Pas encore poussée sur prod-server
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1999Jenkins et SHOULD_*_EXPECTED_FAILS2016-11-29T14:43:03+01:00Vidjil TeamJenkins et SHOULD_*_EXPECTED_FAILSDéjà évoqué ensemble (je n'arrive pas à retrouver de tâche), les (actuellement) 176 failed tests n'aident pas Jenkins à s'y retrouver.
Essai pas propre : 3378b6f (make mark_failed_tests_as_todo). Mais ne fonctionne pas, Jenkins lit au f...Déjà évoqué ensemble (je n'arrive pas à retrouver de tâche), les (actuellement) 176 failed tests n'aident pas Jenkins à s'y retrouver.
Essai pas propre : 3378b6f (make mark_failed_tests_as_todo). Mais ne fonctionne pas, Jenkins lit au fur et à mesure les .tap...
En attendant de trouver mieux, j'ai décoché la case "Failed tests mark build as failure" de coverage et coverage (all slaves)
***
C'est normal que ça ne fonctionne pas : ce n'est pas la règle tests qui est lancée par Jenkins.
***
J'ai ajouté une règle
make -C algo/tests mark_failed_tests_as_todo
dans la configuration du job Vidjil-coverage. Ça passe maintenant.
***
Yeah, merci !
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1998Branche improve_representative2017-12-04T14:55:54+01:00Vidjil TeamBranche improve_representativeOuah, joli boulot, je n'avais pas vu tout cela ! Pas testé, j'ai par contre feuilleté le code.
- Qualité : ce serait bien qu'on ajoute encore des tests (y compris pour les cas de trim de N à l'extérieur). Est-ce qu'il y a aussi des séq...Ouah, joli boulot, je n'avais pas vu tout cela ! Pas testé, j'ai par contre feuilleté le code.
- Qualité : ce serait bien qu'on ajoute encore des tests (y compris pour les cas de trim de N à l'extérieur). Est-ce qu'il y a aussi des séquences réelles où maintenant c'est beacuoup mieux ?
- Vitesse : J'imagine qu'on est toujours globalement linéaire...
Enfin, en rebasant sur "sans-aho" ("improve_representative-sans-aho"), il ne manque que 5f724a6 : est-ce que cela peut se faire tout de même sans aho (et donc potentiellement mergeable cette semaine pour 2016.09 ?)
***
– Qualité : Pour les tests, oui c'est prévu. Les jeux problématiques de la Pitié sont des exemples où cela fonctionne nettement mieux (on passe d'une représentative d'une centaine de bases, à 400nt. Il reste quelques cas où la séquence représentative reste trop courte. Pour qu'elle soit de bonne longueur il faut *diminuer* le nombre de séquences auditionnées (passer de 2000 à 1000 voire 200) ce qui permet d'avoir une proportion plus importante de séquence de bonne qualité. Le problème est que si le clone possède 2000 reads, toutes les séquences seront auditionnées alors qu'il en existe certaines qui sont de mauvaise qualité et qui vont ajouter du bruit.
– Vitesse, pas testé mais c'était prévu aussi. Ça doit rester dans le même ordre de grandeur normalement.
Le 5f724a6 : non cela ne peut pas se faire sans. Pour le coup on sortirait de longues représentatives, mais pas forcément significatives.
***
Hmm... curieux, cela ne passe pas sur mon système décadent :
In file included from germline.cpp:2:
In file included from ./germline.h:8:
./kmerstore.h:384:10: error: no viable overloaded '='
seed = IKmerStore<T>::seed;
~~~~ ^ ~~~~~~~~~~~~~~~~~~~
(En attendant cela passe sur rbx, je regarde fonctionnellement)
***
Avant la release, j'aimerais bien faire passer tout ça sur Jenkins (solution crade, mettre la branche sans-aho temporairement dans la conf du job Jenkins).
Ça compile pour moi avec g++4.9, g++5 et g++6 mais effectivement clang ne passe pas… Je ne comprends pas ce sont juste deux string…
***
Ça devrait être bon pour clang maintenant.
***
Merci, cher magicien.
Je me suis amusé avec data/ambiguous_representative.fa. Cela marche bien pour l'extension (pas de N à l'extérieur, s'arrête au bon endroit). Par contre le premier N passe en A, c'est un effet de bord des k-mers ?
***
> Avant la release, j'aimerais bien faire passer tout ça sur Jenkins
Oui. Ne t'embête pas avec Jenkins : Ce soir, je fais une séance de black git et je remets tout cela sur dev.
***
ambiguous_representative.fa: intéressant. Il y avait ce problème-là mais du coup je suis passé à un index pour chaque graîne (j'étais réticent au début, mais ça ne doit pas changer grand chose en terme de temps de calcul, un peu en espace mais on est sur de petites donnée). Je regarde à quoi c'est dû.
***
Tu m'autorises à tricher ? C'est à cause de la faible complexité de la séquence, on a deux fois la même graîne (--A--T--A--A--C--C--C--T--T--T) qui matche dans la séquence 2 et du coup lors du match « inattendu » cela couvre la position censée contenir le N.
Modifier une position permet d'augmenter la complexité et d'éviter le hit. J'ai commité un truc, tu en fais ce que tu veux.
***
Bien sûr, tricherie acceptée ! Merci.
***
(j'avais du d'ailleurs m'y reprendre à plusieurs fois avant de trouver des "noisy sequences" qui n'étendaient pas d'un nucléotide la représentative)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1997Garder des séquences d'intérêt : -W / -@2019-01-17T15:04:49+01:00Vidjil TeamGarder des séquences d'intérêt : -W / -@(voir aussi "Permettre à certaines séquences de forcer le -t dans le fuse")
Mikaël : 14602c22
DNA sequences that should be found in the window (or windows that should be found into it) can be kept whatever their concentration is. We the...(voir aussi "Permettre à certaines séquences de forcer le -t dans le fuse")
Mikaël : 14602c22
DNA sequences that should be found in the window (or windows that should be found into it) can be kept whatever their concentration is. We therefore mimick what is done for labelled windows. As the two methods looks similar (while this one seems more general), we may want to remove the -W option, to keep only this new -@ option.
Mathieu :
Effectivement, cela m’a l’air plus général
… mais, si j’ai bien compris, -@ avec une séquence de la taille de la fenêtre est quasiment équivalent à -W (est-ce que cela fait bien la même interaction avec -F comme sans -F ?)
Bref :
- autant appeler la nouvelle option « -W », c’est rétro-compatible ?
- voir si cela vaut le coup d’avoir, comme avant, une map <string, string> et non pas une list<string>.
Les labels en questions servaient aussi dans « -l », mais bon, je ne suis pas sûr qu’on s’en sert beaucoup. Mais si on remet au goût du jour, on pourrait mieux se servir de ces labels.
***
yeah, merci
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1993vidjil/segmenter: utiliser le .vidjil2017-04-11T04:37:31+02:00Vidjil Teamvidjil/segmenter: utiliser le .vidjil-c segment sort désormais un .vidjil.
Afficher un segmenteur du browser ? Autre chose ?
***
@nobody-c segment sort désormais un .vidjil.
Afficher un segmenteur du browser ? Autre chose ?
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1992app/analyze: exposer/documenter une API2023-03-28T16:21:00+02:00Vidjil Teamapp/analyze: exposer/documenter une APIShugay et d'autres seraient contents de pouvoir utiliser cela.
(Mais attention, pour l'instant bloquant pour le reste du serveur ?)
***
@nobodyShugay et d'autres seraient contents de pouvoir utiliser cela.
(Mais attention, pour l'instant bloquant pour le reste du serveur ?)
***
@nobodyWeb 2022.12https://gitlab.inria.fr/vidjil/vidjil/-/issues/1991Release 2016.092016-11-29T14:42:58+01:00Vidjil TeamRelease 2016.09- la première release avec aho (pour l'instant silencieux ou pas ?)
- max_similarity 20
- pb de représentative : à voir sérieusement, hotfix et autres
À faire au pire avant EC-NGS, donc jeudi prochain
De plus, cela fait *très* longte...- la première release avec aho (pour l'instant silencieux ou pas ?)
- max_similarity 20
- pb de représentative : à voir sérieusement, hotfix et autres
À faire au pire avant EC-NGS, donc jeudi prochain
De plus, cela fait *très* longtemps qu'on a pas communiqué/spammé tous les utilisateurs (pas fait cet été, finalement).
***
- aho : n'a pas été mergé complètement. Un merge maintenant fait pas mal de conflits
***
aho : désolé, c'est moi qui juste après 2016.08 n'a pas fait de pull incluant ton dernier boulot.
-> branche sans-aho, rebasée sur 2016.08 en enlevant juste le merge loupé.
et... aho se merge quasi-parfaitement dessus !
Proposition : on travaille sur sans-aho, on release 2016.09, puis on merge proprement aho.
***
(on pourrait même merger directement aho sur sans-aho... mais cela risque de rajouter des choses à controller pour la release de jeudi prochain ou d'avant, à voir)
***
Ok.
Il faut aussi intégrer/modifier/améliorer hotfix_evalue_incomplete_germline
***
sans-aho : Il y a 0cb9a9f, 9bac43b et 4fc1c8c qui ont un lien avec Aho. Je les avais mis dans dev, car après le merge. Cela casse les tests, qu'en fait-on ?
***
Rebasé à l'instant sans-aho en enlevant ces trois commits + poussé les trois commits sur aho.
***
+ fait la même opération pour les deux commits "chimera.should-get: We segment again on IGL by chance" et "chimera.should-get: We expect just one sequence to be ambiguous"
(à chaque fois je fais rebase -i master)
***
Il ne manque plus que
- DDJ ?
- improve_representative_sans-aho (si cela passe) ?
***
-improve-representative_sans-aho passe
- DDJ argh… je savais bien que j'avais un autre truc, ça doit être bon je vérifie.
***
Chez moi sans-aho (synchro avec origin/sans-aho, pas de modifs en plus) ne passe pas avec les shouldvdj (170 tests échoués au lieu de 168…). Je fais comment pour trouver le coupable ? ;)
***
1) Tu passes EXPECTED à 85 pour que les tests passent
2) Tu fais un "make snapshot_diff", et tu regardes en particulier le début (out/should-vdj.log)
***
Non, il y a beaucoup mieux maintenant :
Sans rien toucher, faire "make snapshot_diff_current", cela fait un shapshot du truc en cours (pas forcément réussi, donc) puis un diff avec le dernier snapshot réussi
***
Il ne reste donc que DDJ :-)
***
@magiraud @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1987Ajouter l'organisme dans le fichier .vidjil2017-02-02T12:39:25+01:00Vidjil TeamAjouter l'organisme dans le fichier .vidjilUn fichier .vidjil donne le locus mais pas l'espèce. Impossible alors de savoir si un fichier avec un germline IGH provient d'un humain ou d'une souris.
***
@nobodyUn fichier .vidjil donne le locus mais pas l'espèce. Impossible alors de savoir si un fichier avec un germline IGH provient d'un humain ou d'une souris.
***
@nobodyAlgo 2017.03https://gitlab.inria.fr/vidjil/vidjil/-/issues/1986Affichage des logs du serveur web2023-06-28T16:37:56+02:00Vidjil TeamAffichage des logs du serveur webDans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs V...Dans le panneau d'admin, les logs serveurs peuvent être affichés et c'est le fichier « ../log/nginx/access.log » qui est affiché (ou error.log pour les erreurs). Ce n'est pas très générique puisque cela dépend de l'emplacement des logs Vidjil, des logs du serveur web, du serveur web lui-même et des droits affectés au fichier.
Au passage j'aurais bien ajouté une vérification dans showlog pour que showlog ne montre que les logs de Vidjil (et donc empêche de se balader où on veut dans l'arborescence).
Bref je retirerais bien ces deux liens.
***
@magiraud @RyanHerb @mikael-shttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1985Requêtes incessantes à scheduler_task et scheduler_worker2017-12-19T09:46:45+01:00Vidjil TeamRequêtes incessantes à scheduler_task et scheduler_workerIl s'agit initialement d'un mail envoyé à Marc, mais un autre problème avait surgi et on avait mis ça de côté :
Sur le serveur de prod, le process mysql est régulièrement au dessus de 10-20% de CPU.
J'ai loggé les requêtes et il y a pl...Il s'agit initialement d'un mail envoyé à Marc, mais un autre problème avait surgi et on avait mis ça de côté :
Sur le serveur de prod, le process mysql est régulièrement au dessus de 10-20% de CPU.
J'ai loggé les requêtes et il y a plusieurs requêtes par seconde ayant un lien avec les workers et les schedulers alors qu'aucun process n'est queued ou assigned.
Il s'agit de requête du genre :
SELECT scheduler_task.id, scheduler_task.application_name, scheduler_task.task_name, scheduler_task.group_name, scheduler_task.status, scheduler_task.function_name, scheduler_task.uuid, scheduler_task.args, scheduler_task.vars, scheduler_task.enabled, scheduler_task.start_time, scheduler_task.next_run_time, scheduler_task.stop_time, scheduler_task.repeats, scheduler_task.retry_failed, scheduler_task.period, scheduler_task.prevent_drift, scheduler_task.timeout, scheduler_task.sync_output, scheduler_task.times_run, scheduler_task.times_failed, scheduler_task.last_run_time, scheduler_task.assigned_worker_name FROM scheduler_task WHERE ((scheduler_task.assigned_worker_name = 'rbx.vidjil.org#26682') AND (scheduler_task.status = 'ASSIGNED')) ORDER BY scheduler_task.next_run_time LIMIT 1 OFFSET 0
et
SELECT scheduler_worker.id, scheduler_worker.worker_name, scheduler_worker.first_heartbeat, scheduler_worker.last_heartbeat, scheduler_worker.status, scheduler_worker.is_ticker, scheduler_worker.group_names, scheduler_worker.worker_stats FROM scheduler_worker WHERE (scheduler_worker.worker_name = 'rbx.vidjil.org#9626')
Les (anciennes) requêtes sont loggées dans /var/log/mysql/mysql_general.log. J'ai désactivé le log pour ne pas saturer le disque. Pour réactiver, il faut aller dans /etc/mysql/my.cnf, chercher general, décommenter les deux lignes en lien avec general_log et redémarrer le serveur mysql.
***
Dev et test ont maintenant un Heartbeat de 10 secondes, rbx un Heartbeat de 3 secondes (inchangé), la charge de la bdd semble être réduite.
***
On est effectivement passés à environ 3,1 requêtes par seconde, ce qui semble cohérent.
D'après les valeurs que tu donnes, en l'espace de 30 secondes on va avoir 3 heartbeats de chaque worker de dev et de test (soit au total 3 heartbeats * 3 workers * 2 serveurs = 18 heartbeats) et on va en avoir 10 pour rbx ( * 3 workers, soit 30 heartbeats). On arrive à 48 heartbeats en 30 secondes, soit environ 1,6 par seconde. Chaque heartbeat semble générer 2 requêtes, ce qui donne 3,2 requêtes par seconde. On tombe pas loin de ce que j'ai mesuré.
On pourrait diminuer encore du côté de dev et test, mais au final ça ne changerait pas grand chose puisque maintenant c'est rbx qui fait le plus de heartbeats.
***
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1984Le -c segment devrait sortir un .vidjil2016-11-29T14:42:53+01:00Vidjil TeamLe -c segment devrait sortir un .vidjilSouhait de Mikaël, en particulier pour que app.vidjil.org/vidjil/segmenter puisse embarquer un segment.js
***
ffebf9a
***
@magiraud @mikael-s @DuezSouhait de Mikaël, en particulier pour que app.vidjil.org/vidjil/segmenter puisse embarquer un segment.js
***
ffebf9a
***
@magiraud @mikael-s @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1983SampleSets : controlleurs génériques2017-05-19T14:56:23+02:00Vidjil TeamSampleSets : controlleurs génériquesCe serait agréable de pouvoir utiliser des SampleSet génériques (tout en gardant les vues patients et runs).
***
Au programme de la visite de Ryan à Bristol ?
***
@RyanHerb @DuezCe serait agréable de pouvoir utiliser des SampleSet génériques (tout en gardant les vues patients et runs).
***
Au programme de la visite de Ryan à Bristol ?
***
@RyanHerb @Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1982Décalage des informations sous la séquence dans le segmenter2021-04-08T08:29:33+02:00Vidjil TeamDécalage des informations sous la séquence dans le segmenterSur ma machine sous FF j'ai un décalage des informations dans le segmenteur (par exemple avec la qualité ou les affectValues), cf. copie d'écran. Ce décalage est beaucoup plus modéré sous Chromium (environ 1 nucléotide).
***
@nobodySur ma machine sous FF j'ai un décalage des informations dans le segmenteur (par exemple avec la qualité ou les affectValues), cf. copie d'écran. Ce décalage est beaucoup plus modéré sous Chromium (environ 1 nucléotide).
***
@nobodyRyan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1980Titre de la page HTML parfois faux ?2018-04-16T15:49:37+02:00Vidjil TeamTitre de la page HTML parfois faux ?(Aurélie ?) Dans compare patients / dans runs ? À vérifier.
***
@nobody(Aurélie ?) Dans compare patients / dans runs ? À vérifier.
***
@nobodyhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/1979Titre du rapport exporté faux quand "compare patients" et runs2018-04-16T15:49:37+02:00Vidjil TeamTitre du rapport exporté faux quand "compare patients" et runsAurélie : On voit le titre du dernier patient.
***
Confirmé.
***
1. Ouvrir un patient
2. Faire « open patient list »
3. Compare patients
4. Sélectionner des patients (autres)
5. Export report (monitor). Le titre est celui du pati...Aurélie : On voit le titre du dernier patient.
***
Confirmé.
***
1. Ouvrir un patient
2. Faire « open patient list »
3. Compare patients
4. Sélectionner des patients (autres)
5. Export report (monitor). Le titre est celui du patient ouvert au 1.
***
Idem pour les runs : il n'affiche pas le nom du run mais le nom du dernier patient ouvert.
(this.m.patient_name dans export.js, rempli directement par ce que renvoie le serveur)
***
@Duez @magiraud @RyanHerb Web 2017.03Ryan HerbertRyan Herbert