|
|
### a better way of managing supan list
|
|
|
|
|
|
[a better way of managing supan list](https://gitlab.fusiondirectory.org/fusiondirectory/fd-plugins/-/issues/6047)
|
|
|
|
|
|
la raison est ca [Mises à jour FD et /etc/fusiondirectory/supann/](https://gitlab.opensides.be/telecomsudparis/Migration-FusionDirectory-OpenLDAP/-/issues/103)
|
|
|
|
|
|
**mais ca nous a ete demande regulierement sur le problemes de la gestion des horribles listes supann :)**
|
|
|
|
|
|
*C’est pas un problème de packaging? Si j’ai bien suivi les fichiers étaient pas correctement marqués comme fichiers de configurations.*
|
|
|
|
|
|
**ca c'est un side effect a tu lu le ticket 6047 ?**
|
|
|
|
|
|
*Je l’ai lu mais justement pour moi c’est un soucis de packaging, avec des fichiers marqués comme configuration ils ne sont pas écrasés par les mises à jour, et permettent au contraire de vérifier les différences et gérer la continuité ce qui sera impossible dans le LDAP.*
|
|
|
|
|
|
*Il parle de quel partie exactement enfaite, car si ce sont des custom il doit utiliser les moyens custom mis a disposition*
|
|
|
|
|
|
**non c'est le probleme que les listes supan sont longue que les gens on besoin de -10% des listes et que ca cause un probleme fonctionnel pour les utilisateurs qui ne savant pas quoi choisir**
|
|
|
|
|
|
*Le souci c'est aussi de savoir ce qui ont besoin, c'est pas possible de leur proposer d'entrer que ce qui ont besoin non plus à mon avis. Ceux du package sont un peu ceux "par défaut" il me semble. On pourrait les importer dans le LDAP, mais à mon avis ça devrait optimiser quelque chose du coup.*
|
|
|
|
|
|
**Comme le precise mon ticket on parle de deux fonctionnement conjoint, les fichiers restent present et on peut les basculer en config.**
|
|
|
|
|
|
**Mais il faut fournir la possibilite de desactiver les fichiers quand les utilisateurs on besoin de 10 entrees au lieu de 3000 :) d'ou la possibilite de choisir ces propres données stocker dans le backend de config, ily a bien une norme venant de la bcn mais dans la "vraie vie" (tm) ya pas mal de variantes ou de nettoyage a faire :/**
|
|
|
|
|
|
*Le nettoyage c'est dans le sens qui utilise que quelques entrées défini dans les fichiers ou qui doivent les modifier ?*
|
|
|
|
|
|
*Le soucis dans ce cas là c’est qu’idéalement on aurait un peu besoins de deux listes, celles des valeurs proposées à l’entrée, et celle des valeurs valides. C’est un peu dangereux de restreindre les valeurs de la norme si jamais après on a des données qui viennent d’autres établissements. Après je me rends pas compte peut-être que c’est très rare qu’on reste dans un cadre interne le plus souvent.*
|
|
|
|
|
|
**oui c'est bien cela le probleme qu'on essaye de regler et qui est une demande recurrente comment je nettoie ces listes des milliers d'entree dont j'ai pas besoin et je pense pas qu'il faille deux liste on parle vraiment de switch**
|
|
|
|
|
|
*Peux-tu expliquer quels problèmes ça pose de modifier les fichiers?*
|
|
|
|
|
|
**encodage, edition, transfert, il faut imaginer que ce ne sont pas necessairement les informaticiens qui sont au courant des donnees, pour l'instant il le font car personne d'utre pourrait le faire dans le cadre actuel.**
|
|
|
|
|
|
**packaging aussi car actuellement on écrase vu qu'on suit ceux de la norme**
|
|
|
|
|
|
*Une solution si c'est bien de garder que certaines entrées des fichiers ce serait en effet de proposé une commande d'import et de pouvoir les gerer dans FD, mais ça ne doit pas etre une option de suppression ligne par ligne je verrai plus ça comme une liste de management (comme les serveurs, user, etc) car si y doivent supprimer 3000 objets ligne par ligne y sont pas sorti de l'auberge*
|
|
|
|
|
|
**en effet je ne voyais pas ca comme un import mais comme une version light qui bypasse la lecture des fichiers pour certaines categories avec en effet d style management pour gerer ces listes**
|
|
|
|
|
|
*C’est tout le problème c’est des trucs très volumineux c’est pour ça que ça me parait beaucoup plus facile à manipuler sous la forme de fichiers. Que ce soit 30000 nœuds LDAP ou un attribut LDAP avec 30000 valeurs ça va être problématique.*
|
|
|
|
|
|
*On pourrait aussi essayer de mieux documenter la partie sur les fichiers custom et d'avoir un switch de proposer que la version custom pour les fichier originaux par exemple activite\_CNU si on a activite\_CNU\_custom on prend que le custom.*
|
|
|
|
|
|
**le custom a ete implemente a l'epoque pour esssayer de gere ce probleme mais ca ne correspont pas au besoin en final car quand je l'explique on me dit tjrs oui mais ya toujours les autres listes et ca gene les utilisateurs**
|
|
|
|
|
|
*Qu’est-ce que tu appelles custom ici?*
|
|
|
|
|
|
[Supann Custom List](https://fusiondirectory-user-manual.readthedocs.io/en/1.4/fusiondirectory/plugins/supann/users/supann-custom-lists.html)
|
|
|
|
|
|
Ca permetrait qui aie moins d'éléments d'afficher, après y a pas de gestion évolutive au fil du temps (a moins de touché au serveur)
|
|
|
|
|
|
Ça ça vient de la norme SupAnn certains champs autorises des nomenclatures annexes avec une étiquette précises.
|
|
|
|
|
|
ok donc j'ai confondu je vais relire la norme et la rajouter dans la doc
|
|
|
|
|
|
Si tu fais un diplome\_CUSTOM ça va faire des valeurs préfixées {CUSTOM} je crois.
|
|
|
|
|
|
À noter que sur demande de Gallak on autorise ce type d’extension dans plus de champs que ce qu’autorise explicitement la norme. Mais notre logique ici est que si la norme spécifie que les valeurs sont étiquetées avec par exemple un {SUPANN} pour la nomenclature de la norme, on considère qu’elle a bien prévu que ce soit étendu un jour.
|
|
|
|
|
|
**Est-ce qu’une solution ici serait pas simplement de permettre aux gens de choisir quelle liste est utilisée par défaut?**
|
|
|
|
|
|
*Tu veux dire par rapport au fichier sur le serveur ?*
|
|
|
|
|
|
Je veux dire pouvoir dire que pour entite ça présélectionne «INSA» plutôt que «SUPANN» en imaginant que ya un entite\_INSA qui a été ajouté. (actuellement ya rien de préselectionné dans les cas où le champ est pas obligatoire parce qu’on considère que pas de valeur = pas de liste sélectionné, mais on pourrait changer ça par une liste par défaut et gérer la valeurs vide dans le deuxième champ, pour éviter un rechargement de page chaque fois qu’on touche à ce type de champ quand on utilise toujours des valeurs de la même liste, ce qui doit être le cas général)
|
|
|
|
|
|
|
|
|
|
|
|
*Ca peut regler le souci que ça gene d'avoir trop d'entrée de visible, en général on modifie que 1 fois les listes ou c'est possible que ce soi évolutif bilbo ? Si ce n'est qu'une fois ça me semble etre pas mal comme solution, y devront toujours toucher au fichier mais si c'est que 1 fois pour créer les fichiers custom *
|
|
|
|
|
|
*Attention tu confonds deux cas, Benoit parlait aussi de situations où les utilisateurs veulent utiliser des valeurs de la norme mais en retirer les lignes qu’ils utilisent pas, auquel cas ça peut pas se faire par un fichier autre que celui qui a l’étiquette de la norme. (par contre oui normalement ya besoin de modifier une seule fois)*
|
|
|
|
|
|
**en effet je parle de la flexibilite de gestion de l'enselble des listes, un cas courant est la liste des diplome, des disciplines ... et croire que ca ne vas changer qu'un fois dans l'education comment dire .... marmotte met le chocolat dans le papier alu :)**
|
|
|
|
|
|
**Car si on veut de la flexibilité on échapera pas à devoir l'avoir dans l'interface à mon avis car ça devra être gerer par des non informatiens je suppose**
|
|
|
|
|
|
**pour ca que j'ai evoquer le switch car je suis sur que certains voudront changer certaines listes et d'autre d'autres listes et donc faut de la flexibilite, ce que je suis sur c'est que j'ai passe des heures de discussions dans differents projet sur gngigigigigi on peut pas changer ces listes **
|
|
|
|
|
|
**en ce qui concerne l'edition des listes on a eu des gros problemes chez condorcet :) et gallak a renoncer a les editer et eri me tanne a chaque fois :)**
|
|
|
|
|
|
*Je voulais en parler avec Gallak mais il est pas là en ce moment j’ai l’impression*
|
|
|
|
|
|
*Encore une fois si les listes étaient écrasées à chaque mise à jour je comprends bien que ça pose problème.*
|
|
|
|
|
|
*Benoit tu peux faire une proposition d’interface et de stockage parce que j’ai bien du mal à imaginer autre chose qu’une page qui permet d’uploader un fichier, je vois mal les gens copier des valeurs une par une de la BCN ou de leurs listes internes dans des champs FD, c’est des listes qui restent longues.*
|
|
|
|
|
|
**oui je pense qe ca se decompose en plusieurs partie**
|
|
|
|
|
|
* importation de liste nettoyee par type peut etre avec notre import csv dans les listes correspondantes du backend de configuration, profiter de l'opportunite pour ameliorer l'import csv ?
|
|
|
* L’import CSV crée les objets, je penses pas qu’on fasse un type d’objet pour les éléments de liste supann si?
|
|
|
* non en effet ce sont des attributs, mais pourrait t'on l'elargir a gere notre backend de config, simple question ?
|
|
|
* Pas facilement, mais surtout les listes seront probablement pas directement dans l’objet configuration.
|
|
|
* pourquoi ne serait elles pas dans le backend de configuration on aurait un autre endroit ou les stocker ? ca generait qu'elles soient dans le backend de configuration, ca sera des listes simple je n'imagine pas des listes de 2000 dans le backend de configuration mais on peut en discuter avec les communaute et les clients
|
|
|
* Il y a 30000 valeurs dans les listes supann actuellement. Rien que fusiondirectory-setup --show-config devient complètement inutile si ya 1000 lignes de norme supann au milieu.
|
|
|
* ok donc le plugin supann devra comprendre son propre gestionnaire de liste ca sera discuter en effet faut voir ce que les utilisateurs vont dire
|
|
|
* les listes de mémoire c'est "nom afficher" => attribut (quelque chose du genre c'est ça ?)
|
|
|
* Je dis ptet une horreur mais pourquoi pour l’édition on met pas juste une grosse textarea avec tout le contenu? Ça permet de gérer aussi facilement que dans un fichier, parce sinon pour supprimer ou remplacer beaucoup de valeurs ça va être la course au clic ils font se casser tous les doigts. Ça permet aussi le copier/coller, et de partir plus facilement de l’existant ou des exports BCN. Après faut voir si on peut passer 27000 lignes en POST pour le cas des diplômes.
|
|
|
* -> j’ai testé par curiosité 27000 lignes en POST ça passe donc a priori ya pas de limitation technique qui s’oppose à avoir une textarea pour éditer la liste.
|
|
|
* toi tu veux des crise de nerf :) :) non faut un truc simple et pense mais je repete j'ai pas l'intention de charger des miliers de lignes :) l'idee est justement de faire de l'epure
|
|
|
* Je comprends pas justement je voulais éviter les crises de nerfs et faire un truc simple.ce qui semble simple ne l'est pas toujours quand on a des utilisateurs en face de soi :)
|
|
|
* Donc quelle interface tu verrais qui permet de manipuler les lignes, réordonner, modifier, supprimer en masse, … ?
|
|
|
* je penses que la première création sera pas vraiment un souci, si y a pas d'import comme du csv, on peut imaginer d'autre forme avec le webservice je sais pas si niveau gestion une textarea serait plus simple pour les clients (faudrait leur retour la dessus)
|
|
|
* redesign de l'onglet supann du backend de configuration peut etre pour le diviser en plusieurs onglets
|
|
|
* default
|
|
|
* carte multi service
|
|
|
* listes supann
|
|
|
* Dans le backend de configuration sur la page liste on met une checkbox pour dire si la liste est active ou pas, ce qui procure l'info sur quoi charger dans la liste deroulante
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*Pour ça ils peuvent personnaliser les fichiers. ca ne marche pas et cuase d'autre probleme deja vecu => quels problèmes?*
|
|
|
|
|
|
*(Après on peut aussi y voir un problème d’interface, c’est rageant que les navigateurs aient jamais implémenté un truc plus sérieux avec recherche pour les select, comme ce qui existe dans les frameworks pleins de javascript.)*
|
|
|
|
|
|
*Note: j’ai jamais eu de réponse sur la liste esr pour retirer les valeurs obsolètes, ce qui simplifierai déjà un peu les listes.*
|
|
|
|
|
|
### Avantages du stockage par fichiers (marqués comme fichiers de configuration)
|
|
|
|
|
|
* Cela permet la mise à jour des fichiers par FusionDirectory pour suivre les évolutions de la norme SupAnn, et corriger les éventuelles erreurs
|
|
|
* Cela peut permettre lors des mises à jour de comparer sa version avec celle du mainteneur
|
|
|
* Cela peut faciliter le partage de nomenclatures entre les utilisateurs si nécessaire
|
|
|
* Pour la plupart des fichiers il est facile de les générer depuis la BCN pour comparaison
|
|
|
|
|
|
**ok on peut finir la premiere reunion ici je vais commencer le design d'une proposition et on ira en parler chez les clients**
|
|
|
|
|
|
|