vidjil issueshttps://gitlab.inria.fr/vidjil/vidjil/-/issues2021-02-03T09:09:32+01:00https://gitlab.inria.fr/vidjil/vidjil/-/issues/3360Gestion plus propre des warnings2021-02-03T09:09:32+01:00Mikaël SalsonGestion plus propre des warningsPour l'instant l'ajout d'un warning se fait dans le JSON. Si on veut afficher quelque chose sur la sortie standard c'est géré indépendamment, avec des messages qui peuvent diverger.
Ce n'est donc pas très générique.
De plus l'ajout d'un...Pour l'instant l'ajout d'un warning se fait dans le JSON. Si on veut afficher quelque chose sur la sortie standard c'est géré indépendamment, avec des messages qui peuvent diverger.
Ce n'est donc pas très générique.
De plus l'ajout d'un warning dans le JSON se fait par un code unique, sous forme de chaîne, suivie d'une description.
Plusieurs éléments :
* [ ] Ne pourrait-on pas avoir une constante pour chaque warning (toujours préférable aux chaînes pour lesquelles on risque une typo) ?
* [ ] Le message ne peut-il pas être mis automatiquement (tous définis dans un tableau commun) plutôt que d'avoir à le réécrire à chaque fois ?
* [x] Les warnings ne peuvent-ils pas exister indépendamment du JSON ? Ensuite c'est chaque type de sortie qui définit ce qu'elle fait du warning.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3084germline_id, *.g et vidjil-algo2020-11-19T08:41:57+01:00Mathieu Giraudgermline_id, *.g et vidjil-algoSuite à !158, cela me tenterait presque de déplacer `germline_id` dans `algo/`. En effet, `germline_id` est bien la version des germlines utilisée par l'algo.
En effet `germline/` est autonome, avec ses tests. On peut désormais faire év...Suite à !158, cela me tenterait presque de déplacer `germline_id` dans `algo/`. En effet, `germline_id` est bien la version des germlines utilisée par l'algo.
En effet `germline/` est autonome, avec ses tests. On peut désormais faire évoluer les germlines, travailler sur `split-from-imgt`, faire les tests qui vont avec sans casser l'algo. Quand on est content, on met à jour `germline_id` et on travaille sur l'algo.
Problème : on trouve aussi ces numéros de versions dans les `*.g` (mais qui sont aussi, quelque part, des choses plutôt algo).
Voir #1491.https://gitlab.inria.fr/vidjil/vidjil/-/issues/3064Stats : controlleur 'stats' vs controlleur 'compare patients' vs controlleur ...2018-02-27T14:29:40+01:00Mathieu GiraudStats : controlleur 'stats' vs controlleur 'compare patients' vs controlleur 'set'A-t-on besoin de trois controlleurs différents ?
cc @RyanHerbA-t-on besoin de trois controlleurs différents ?
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2959Groupe public géré par web2py2018-01-08T09:54:07+01:00Mathieu GiraudGroupe public géré par web2pyNous gérons nous-même le groupe public.
Il y a aussi `everybody_group_id` dans `Auth` (et donc dans `VidjilAuth`), qui apparamment gère aussi `has_permission`. Je ne sais pas si cela vaudrait le coup ou pas de l'utiliser pour ne plus le...Nous gérons nous-même le groupe public.
Il y a aussi `everybody_group_id` dans `Auth` (et donc dans `VidjilAuth`), qui apparamment gère aussi `has_permission`. Je ne sais pas si cela vaudrait le coup ou pas de l'utiliser pour ne plus le faire de notre côté.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2747Organiser les sample_sets par projet pour accélérer les requêtes2020-09-23T17:32:47+02:00Ryan HerbertOrganiser les sample_sets par projet pour accélérer les requêtesActuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la no...Actuellement on a un système qui est très flexible en termes de permissions et d'associations de samples à plusieurs sets, voire plusieurs groupes. Mais c'est aussi plutôt lent à cause du système de permissions que j'ai créé.
Avec la notion de hierarchie de groupes, on se retrouve avec des requêtes plutôt complexes pour déterminer si l'utilisateur a accès à un élément.
> Il faut chercher si l'utilisateur appartient à un groupe qui a la permission `access` ou à un groupe dont le parent a la permission `access`
Donc lister les sets d'un type particulier auxquels un utilisateur a accès revient au code suivant:
``` python
def vidjil_accessible_query(self, name, table, user_id=None):
"""
Returns a query with all accessible records for user_id or
the current logged in user
this method does not work on GAE because uses JOIN and IN
This is an adaptation of accessible_query that better fits
the current auth system with group associations
:param: name: The name of the query (eg. 'read')
:param: table: The table for accessibility
:param: user_id: ID of the user
Example:
Use as::
db(auth.vidjil_accessible_query('read', db.mytable, 1)).select(db.mytable.ALL)
"""
if not user_id:
user_id = self.user_id
db = self.db
if isinstance(table, str) and table in self.db.tables():
table = self.db[table]
elif isinstance(table, (Set, Query)):
# experimental: build a chained query for all tables
if isinstance(table, Set):
cquery = table.query
else:
cquery = table
tablenames = db._adapter.tables(cquery)
for tablename in tablenames:
cquery &= self.vidjil_accessible_query(name, tablename,
user_id=user_id)
return cquery
if not isinstance(table, str) and\
self.has_permission(name, table, 0, user_id):
return table.id > 0
membership = self.table_membership()
permission = self.table_permission()
perm_groups = self.get_permission_groups(name, user_id)
query = (table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)) |
table.id.belongs(
db(((membership.user_id == user_id) &
(membership.group_id.belongs(perm_groups)) &
(membership.group_id == db.group_assoc.second_group_id) &
(db.group_assoc.first_group_id == permission.group_id) &
(permission.name == PermissionEnum.access.value) &
(permission.table_name == table)))._select(permission.record_id)))
if self.settings.everybody_group_id:
query |= table.id.belongs(
db(permission.group_id == self.settings.everybody_group_id)
(permission.name == name)
(permission.table_name == table)
._select(permission.record_id))
return query
```
Ce qui produit la requête SQL suivante:
```sql
SELECT `patient`.`id`, `patient`.`first_name`, `patient`.`last_name`, `patient`.`birth`, `patient`.`info`, `patient`.`id_label`, `patient`.`creator`, `patient`.`sample_set_id` FROM `patient`
WHERE (
(`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`
WHERE (
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
))
)
OR (`patient`.`id` IN
(SELECT `auth_permission`.`record_id` FROM `auth_permission`, `auth_membership`, `group_assoc`
WHERE (
(
(
(
(
(`auth_membership`.`user_id` = 2)
AND (`auth_membership`.`group_id` IN (4))
)
AND (`auth_membership`.`group_id` = `group_assoc`.`second_group_id`)
) AND (`group_assoc`.`first_group_id` = `auth_permission`.`group_id`)
) AND (`auth_permission`.`name` = 'access')
) AND (`auth_permission`.`table_name` = 'patient')
)
)
));
```
On a donc une requête composée de deux sous-requêtes chacune contenant un `IN` aussi long que le nombre de groupes auxquels l'utilisateur appartient, l'une avec un `join` et l'autre avec deux `join` (ici les joins sont implicites).
Et les autres primitives du model `VidjilAuth` sont composées de plusieurs `joins` et souvent plusieurs requêtes.
Avec une organisation par projet (avec une nouvelle table, et une clef étrangère dans la table `sample_set`) on pourrait se débarrasser complètement de la permission `access`, et par la même occasion on laisse tomber cette anbiguïté qu'on a avec les groupes de projets/hôpitaux et les groupes de rôles/permissions.
La requête "patient" deviendrait:
```python
def get_project_sets(type, project_id):
return db(
(db.sample_set.project_id == project_id) &
(db.sample_set.sample_type == type) &
(db[type].sample_set_id == db.sample_set.id)
).select(db[type].*)
```
Avec auparavant avoir vérifié que l'utilisateur ait accès à un groupe/rôle apparetenant au projet (2 joins sur relativement peu de données). Ce qui nous donne un total de 4 joins sur deux requêtes par rapport à un total de 3 joins répartis sur 3 requêtes, et on perd les `IN`
Il y a plusieurs autres endroits où des gains de jointures ou de requêtes seraient aussi envisageables (`get_permission(...)`, `can_view_sample_set(...)`, ...).
Ainsi que des endroits où les requêtes seraient plus complexes ?
J'aurais tendance à vouloir limiter les associations de samples à des sets du même projet car celà simplifierai certaines requêtes, comme l'autocompletiondes tags, et ainsi que celle des samples_sets à l'ajout d'un sample.
Ca éliminerait également l'impacte des grosses requêtes auxquelles nous les admins soumettons la BDD. Et donc on n'occuperait plus un (voire plus) de processus uwsgi pendant des durées prolongées (par exemple, plus d'une minute pour un compare patient).
Cette moification demanderait beaucoup de travail, donc ça ne serait pas pour tout de suite, mais je pense que celà réduirait le nombre de timeouts subis par nos utilisateurs. Celà demanderait peut-être plus d'analyse, de tests et de benchmarks.https://gitlab.inria.fr/vidjil/vidjil/-/issues/2585haml2023-03-01T16:42:41+01:00Mathieu Giraudhaml@RyanHerb a présenté à Douai haml : http://haml.info
Implémentation python ? https://github.com/mikeboers/PyHAML ?@RyanHerb a présenté à Douai haml : http://haml.info
Implémentation python ? https://github.com/mikeboers/PyHAML ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/2438Eviter les initialisations multiples2017-11-14T17:42:00+01:00Ghost UserEviter les initialisations multiplesJe remarque, sans savoir précisément où, que certaines vues sont initialisées plusieurs fois. Par exemple, il y a 3 exécutions de `Builder.init()` à l'ouverture de la page.
C'est sans doute lié à des mécaniques d'`udpate`.
Régler...Je remarque, sans savoir précisément où, que certaines vues sont initialisées plusieurs fois. Par exemple, il y a 3 exécutions de `Builder.init()` à l'ouverture de la page.
C'est sans doute lié à des mécaniques d'`udpate`.
Régler ce souci permettrait certainement de gagner en performance, ou du moins de limiter les appels 'superflus'.Ryan HerbertRyan Herberthttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2201Ne pas avoir de variables globales sur les différentes vues2021-08-10T16:39:43+02:00Mathieu GiraudNe pas avoir de variables globales sur les différentes vuesDiscussion avec @aurelBZH, @mikael-s et @RyanHerb (en partant de #2182 et autres).
On ne devrait pas utiliser de variables globales `sp`, `segment`... pour chaque vue, mais avoir uniquement des appels au modèle.
Les `m.graph` et `m.s...Discussion avec @aurelBZH, @mikael-s et @RyanHerb (en partant de #2182 et autres).
On ne devrait pas utiliser de variables globales `sp`, `segment`... pour chaque vue, mais avoir uniquement des appels au modèle.
Les `m.graph` et `m.sp` ne sont que des hacks temporaires (on pourrait avoir zéro ou plusieurs `sp`, et le code doit fonctionner).
Parmi les pistes évoquées, les vues pourraient s'enregistrer auprès de `shortcut` et `url_obs` (et potentiellement d'autres). Plus généralement, comme les vues s'enregistrent déjà auprès du modèle, une solution pourrait d'avoir des fonctions type `m.getViews(SP)` qui renvoie une *liste* de vues d'un certain type. À réfléchir/discuter encore, pas urgent pour l'instant.
/label ~client ~"!-reflexion" ~"!-hard"
https://gitlab.inria.fr/vidjil/vidjil/-/issues/1559model.js et vues: updateXxx(), découpage judicieux ?2019-11-04T06:50:47+01:00Vidjil Teammodel.js et vues: updateXxx(), découpage judicieux ?La doc devrait mieux expliquer le fonctionnement de `update()` / `updateModel()` / `updateElem()` / `updateElemStyle()` / `updateStyle()` et surtout leur relation entre eux. Je ne sais pas si c'est dans chaque fonction, ou plutôt au débu...La doc devrait mieux expliquer le fonctionnement de `update()` / `updateModel()` / `updateElem()` / `updateElemStyle()` / `updateStyle()` et surtout leur relation entre eux. Je ne sais pas si c'est dans chaque fonction, ou plutôt au début de `model.js`,
J'ai par exemple du mal à comprendre pourquoi `updateModel()` est appelé par certaines fonctions.
@Duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/4147Simplifier scatterplot+graph en extrayant des choses indépendantes, pour les ...2020-01-21T17:03:42+01:00Mathieu GiraudSimplifier scatterplot+graph en extrayant des choses indépendantes, pour les paramètresSuggestion de @duez (en parlant de !565)
Voir aussi #2245.Suggestion de @duez (en parlant de !565)
Voir aussi #2245.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4114axes: refactor GermlineAxis, et plus généralement refactor des axes2020-01-22T15:20:37+01:00Mathieu Giraudaxes: refactor GermlineAxis, et plus généralement refactor des axes@duez est en train de travailler@duez est en train de travaillermarc duezmarc duezhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/3184Factoriser js/form_builder.js et views/partial/file/form.html2018-04-17T14:55:19+02:00Mathieu GiraudFactoriser js/form_builder.js et views/partial/file/form.htmlOn peut vivre avec la duplication actuelle même si ce n'est pas très agréable.
Serait-ce possible de faire un appel de `node ...` sur un `.js` qui regénererait `form.html` à partir de `js/form_builder.js` ? Ou une autre solution dans l'...On peut vivre avec la duplication actuelle même si ce n'est pas très agréable.
Serait-ce possible de faire un appel de `node ...` sur un `.js` qui regénererait `form.html` à partir de `js/form_builder.js` ? Ou une autre solution dans l'autre sens ?
Si c'est trop complexe, pas de soucis, on laisse ainsi.
cc @RyanHerbhttps://gitlab.inria.fr/vidjil/vidjil/-/issues/2700Réduire les différences entre MODE_BAR et MODE_GRID2018-10-03T23:57:38+02:00Mathieu GiraudRéduire les différences entre MODE_BAR et MODE_GRIDY a-t-il des raisons autres qu'historiques qui fait qu'on a tant de différences/recopies entre les deux modes d'affichage ?
- dans `generic_axis.js`, `computeLabels` et `computeBarLabels` sont bien différents (je m'en suis rendu compt...Y a-t-il des raisons autres qu'historiques qui fait qu'on a tant de différences/recopies entre les deux modes d'affichage ?
- dans `generic_axis.js`, `computeLabels` et `computeBarLabels` sont bien différents (je m'en suis rendu compte en essayant de faire #2699, voir !91)
- dans `scatterplot.js`, similarités de codes entre `computeBarTab` utilise `axisX.posBarLabel
Dans `scatterplot.js`, au moment de faire le bar plot, on doit certes avoir une gestion différenciée de l'axe Y. Mais j'ai l'impression que tout ce qui touche l'axe X devrait être identique/générique (et #2394 serait alors naturel). Que ce soit en `BAR` ou en `GRID`, que ce soit en valeurs génériques ou numériques, on peut avoir (ou pas) des valeurs `?`, on a envie d'avoir du `nice_{floor,ceil}` #2699, on peut vouloir (ou pas) zoomer #2431.
cc @RyanHerbWeb 2018.01https://gitlab.inria.fr/vidjil/vidjil/-/issues/5183Py4web; update documentation2024-01-22T14:14:19+01:00THONIER FlorianPy4web; update documentationSome documentation need to be added and updated, on dev, usage, migration, ...Some documentation need to be added and updated, on dev, usage, migration, ...Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5073Migration py4web2024-02-20T15:37:21+01:00Thonier FlorianMigration py4webListe des points à traiter pour py4web, !1121
## bloquant
* [x] nom des samples (+ bloque l'ouverture des résults)
* [x] création user (quelques routes)
* [x] init base de données =\> bloque les tests cypress
* [x] affichage du status ...Liste des points à traiter pour py4web, !1121
## bloquant
* [x] nom des samples (+ bloque l'ouverture des résults)
* [x] création user (quelques routes)
* [x] init base de données =\> bloque les tests cypress
* [x] affichage du status d'une analyse (lien avec la bdd lors de l'avancement) #5076
* [x] rebaser la branche sur `dev`
* [ ] #5180; script migration web2py vers py4web @fthonier
* [x] #5185; Inconstance de la DB (certains appels retournent None alors que présents ou nouvellement créé) @clement.chesnin et @fthonier
* [x] #5190; Pipeline pour les tests unitaires @clement.chesnin
* [x] #5189; check that all download function work
* [x] #5194; download gosu
* [x] #5202; Check pre-process with py4web
* [x] #5204; compare samples fail
* [x] #5210; Fix CGI for py4web
* [x] #5213; loading analysis is not working
* [x] #1397; link to open results
## prioritaire
* [x] custom fuse (contrôleur ou serveur python pour les faire à la volée) ==\> en cours, service d'avant
* [x] convertir test-server_base en py4web (construction/lancement docker sur py4web) ==\> vidjil!1238 @flothoni
* [x] lignes dupliquées dans les sets (pour l'instant pas de limite sample/set; lié au status dans la db)
* [x] liste result sur la page patient, run set (pour l'instant id config, mais pas le lien vers les résultats) ==\> jouable pour Marc
* [x] download results file (ok pour les fused du client, là on parle de dl)
* [x] mettre en place l'archi pour les tests API (si modification) ==\> @duez quelques modifs en cours, on devra continuer #5077
* [x] #5157 et !1342; Verifier API pour les json et le login (les routes restent les mêmes donc pas de souci en théorie, verifier la sortie json) @fthonier
* [x] #5178 parse des erreurs py4web pour les afficher proprement (nb modal qui change la disposition de la page) @fthonier
* [x] #5179 tests unitaires qui n'ont pas de routes (changement de méthode nécessaire) @clement.chesnin
* [ ] doc interne
* [ ] Ensemble des scripts adhoc de web2py compatible py4web ?
* [x] #5191; (client) return that an server error occured when it is
## nettoyage
* [x] #5184; Virer web2py
* [x] #5183; Mettre à jour toute la documentation qui fait référence au serveur web2py
* [x] #5182; Retirer les fichiers de demo de py4web; bulma, vue, ...
## secondaire
* [x] #5078; impersonate (pour l'instant bypass; avancée dans son intégration dans py4web vanilla) @clement.chesnin
* [ ] #5181; fonctionnement du script `create_clone_db.py`
* [x] #5169; Redirection 303 en cas de création d'users @clement.chesnin
* [ ] #5186; Serveur de review @fthonier
* [x] #5187; Se passer de uWSGI ?
* [ ] #2019; état des process + page admin en général
* [x] taille du fichier toujours à 0Web 2024.04https://gitlab.inria.fr/vidjil/vidjil/-/issues/5031germlines/ et python32024-01-31T18:10:53+01:00Mathieu Giraudgermlines/ et python3Les scripts dans germline/ ne se lancent pas sur une machine récente, sans explicitement rajouter des python2 partout.
Voir aussi #2257.Les scripts dans germline/ ne se lancent pas sur une machine récente, sans explicitement rajouter des python2 partout.
Voir aussi #2257.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4930vidjil.cpp: refactor des appels de création des index2022-01-10T09:12:03+01:00Mathieu Giraudvidjil.cpp: refactor des appels de création des indexDepuis #4845, après !1010:
> Pour une remise à plat du bloc création index (et -2/-4/...) on verra plus tard
Voir le [bilan](https://gitlab.inria.fr/vidjil/vidjil/-/issues/4845#note_568484) fait avant !1010.
Voir aussi (orthogonalement...Depuis #4845, après !1010:
> Pour une remise à plat du bloc création index (et -2/-4/...) on verra plus tard
Voir le [bilan](https://gitlab.inria.fr/vidjil/vidjil/-/issues/4845#note_568484) fait avant !1010.
Voir aussi (orthogonalement ?) #2968 et #1169.https://gitlab.inria.fr/vidjil/vidjil/-/issues/4868axis_conf.js : ne pas mélanger identifiants et labels2023-03-28T16:17:31+02:00Mikaël Salsonaxis_conf.js : ne pas mélanger identifiants et labelsDans `axis_conf.js` les identifiants d'axes servent aussi de labels (par exemple `V/5' gene`).
C'est embêtant parce que les identifiants sont utilisés à plusieurs endroits (pour définir quels axes sont utilisés à quel endroit).
1. Qu...Dans `axis_conf.js` les identifiants d'axes servent aussi de labels (par exemple `V/5' gene`).
C'est embêtant parce que les identifiants sont utilisés à plusieurs endroits (pour définir quels axes sont utilisés à quel endroit).
1. Quand on modifie un label, on ne s'attend pas à ce qu'il y ait des effets de bord
2. Il faut chercher tous les endroits où il est utilisé pour les modifier également (ex. 51c11e5f) (et puis avant cela il faut comprendre l'origine du problème… c'est du vécu)
3. Comme ces labels sont aussi des identifiants, ces labels sont aussi utilisés dans les URL. Toute modification d'un label rend donc obsolète les URL précédentes…
4. Comme les identifiants sont des chaînes de caractères, il y a toujours le risque de faire une typo à un endroit et donc d'indiquer un identifiant qui n'existe pas.
Je pense que la solution la plus propre serait que le nom des axes soient définis avec les autres propriétés des axes.Web 2023.10https://gitlab.inria.fr/vidjil/vidjil/-/issues/4777Rationaliser les appels à build_from_json2021-04-28T12:10:42+02:00Mathieu GiraudRationaliser les appels à build_from_jsonVu à l'occasion de #4775: il y a deux fois `multigermline->build_from_json()` très semblables (dans les cas standard, le deuxième lance `homo-sapiens/homo-sapiens.g` et ne mène à rien).
Suite de #3293 ?Vu à l'occasion de #4775: il y a deux fois `multigermline->build_from_json()` très semblables (dans les cas standard, le deuxième lance `homo-sapiens/homo-sapiens.g` et ne mène à rien).
Suite de #3293 ?https://gitlab.inria.fr/vidjil/vidjil/-/issues/4659Vérification d'overlap : le faire aussi sur non up/down (bref les V) + refact...2021-01-20T21:09:19+01:00Mathieu GiraudVérification d'overlap : le faire aussi sur non up/down (bref les V) + refactor split-germlinesC'est plus complexe que les choses dans !891 , mais c'est l'occasion de refactorer `split-germlines.py` pour que le même mécanisme sorte les germlines "normales" que les down/up. Sera fait plus tard.C'est plus complexe que les choses dans !891 , mais c'est l'occasion de refactorer `split-germlines.py` pour que le même mécanisme sorte les germlines "normales" que les down/up. Sera fait plus tard.Mathieu GiraudMathieu Giraud