|
|
Etat du developpement filtres
|
|
|
=======================
|
|
|
|
|
|
Users et groupes semblent fini ?
|
|
|
|
|
|
Il manque toujours la possibilité de sauver la config des colonnes.
|
|
|
Faut voir comment on décide de quels champs sont recherché par la recherche texte.
|
|
|
Ya un refactor à faire pour réutiliser les nouvelles classes de management pour la sélection d’objet (exemple quand on clique sur éditer le manager d’un user on doit tomber sur une classe de management avec les mêmes possibilité que le user management, idéalement les mêmes colonnes que configurées également)
|
|
|
|
|
|
Ya la gestion de la base actuelle à repenser idéalement
|
|
|
$this->base = session::global\_get('CurrentMainBase'); // TODO Replace with config or ui var
|
|
|
|
|
|
Il manque la gestion ACL du menu des actions (cacher les actions que le user est pas autorisé à faire pour aucun type)
|
|
|
|
|
|
Ya un hack un peu vilain pour préfiltrer les attributs demandés en fonction des ACLs faudra voir si on trouve mieux
|
|
|
|
|
|
Faut choisir si on affiche ou pas le filtrage par type quand ya un seul type.
|
|
|
Faut voir si on garde le fonctionnement du filtre templates ou si on le gère différemment
|
|
|
Faut voir quel style CSS on veux donner aux filtres
|
|
|
|
|
|
Etat d'avancement sur le reste de fusiondirectory ?
|
|
|
|
|
|
Ya potentiellement tous les plugins à migrer vers management une fois que ça marche.
|
|
|
|
|
|
durée prévue pour le reste du développement ?
|
|
|
|
|
|
|
|
|
|
|
|
tests à réaliser ?
|
|
|
|
|
|
Les tests selenium déjà :-)
|
|
|
|
|
|
Globalement ça a été testé qu’en admin faut vérifier les comportements quand on a pas tous les droits.
|
|
|
|
|
|
Des tests de performance pour vérifier qu’on a pas trop perdu sur avant aussi. Et un peu de profiling.
|
|
|
|
|
|
peut-on découper les développement qui restent en haut en phase et nombre de jour
|
|
|
|
|
|
* sauver la configuration des colonnes
|
|
|
* J’ai pas trouvé de fonctionnement pratique la dernière fois que j’y ai réfléchis. Ça fait partie des trucs qu’on peut repousser vu que c’est pas une régression.ok
|
|
|
* recherche des champs en mode texte
|
|
|
* Tout dépend de la solution choisie.
|
|
|
* que propose tu ?
|
|
|
* refactor des classes de managment pour la selection d'objets
|
|
|
* Quelques jours sauf gros pépin en cours de route je dirais.
|
|
|
* ok
|
|
|
* gestion de la base
|
|
|
* Faut déjà voir quel comportement on veut, ensuite je pense que ça s’implément rapidement.
|
|
|
* gestion acl du menu actions
|
|
|
* 2 jours je dirais, faut que je replonge dans les problématiques liées.
|
|
|
* Faut choisir si on affiche ou pas le filtrage par type quand ya un seul type.
|
|
|
*
|
|
|
|
|
|
* fonctionnement du menu template
|
|
|
* C’est pas le menu c’est le filtre, faut qu’on voit ce qu’on veut en faire
|
|
|
* que propose tu ?
|
|
|
* écriture des tests
|
|
|
* Ya une petite semaine de tests et corrections à prévoir à un moment, on va faire tourner l’existant adapter les tests et voir ce qui coince déjà
|
|
|
et question finale peut on limiter ce qui doit être corrigé pour condorcet en 1.4 ou doit on se rebattre sur un 1.3-condorcet pour des raisons de timing ?
|
|
|
|
|
|
Je pense qu’on peut prioriser les trucs important et repousser tout ce qui est cosmétique ou nouvelle feature.
|
|
|
|
|
|
Recherche des champs en mode texte:
|
|
|
|
|
|
* Situation actuelle: ça cherche dans cn et description quoi qu’il arrive (sauf si on entre un filtre ldap bien sûr)
|
|
|
* Possibilités:
|
|
|
* - On met en dur dans chaque classe de management où ça cherche
|
|
|
* - On met dans chaque type les champs à chercher et la classe de management merge
|
|
|
* - On rend ça configurable par management ou par type (plutôt par type a priori)
|
|
|
* - On met dans chaque onglet les champs à chercher et la classe de management merge les onglets des types (permet par exemple au plugin mail d’indiquer qu’il faut chercher dans le champ mail des utilisateurs)
|
|
|
* la solution 3 et 4 me plait bien je sais pas la quelle est la meilleure ? ton avis
|
|
|
* Je partirais sur la 4 mais faut voir à l’implémentation si ça se passe bien car ça implique beaucoup de monde (faut que le filtre demande au management qui demande à la classe de tabs qui demande aux onglets etc…)
|
|
|
* Faut voir aussi si ça donne pas trop de champs cherchés, je sais pas l’impact du filtre sur la performance d’une requête LDAP.
|
|
|
* effectivement au plus le filtre est complexe au plus tu as un hit
|
|
|
* Je pense que si on veut contenter tout le monde on va "vite" se retrouver avec une dizaine de champs pour les users. Cela dit ça ne concerne que les recherches texte le reste du temps ça n’a pas d’impact. (Et lors d’une recherche texte pas sûr que le filtre soit le goulot)
|
|
|
* le probleme eventuel de faire tout automatique c'est que les utilisateurs ne pourront pas decider de ou chercher ?mais est ce vraiment un probleme ?
|
|
|
* Ben ils peuvent chercher avec un filter perso de toutes façons
|
|
|
Fonctionnement des filtres:
|
|
|
Filtres par type: Sont affichés tous les objets des types cochés, donc c’est un "ou" entre les types cochés (un nœud ne peut pas être de deux types de toutes façons)
|
|
|
Filtres par onglet: Sont affichés les objets ayant TOUS les onglets cochés activés, donc c’est un "et" entre les onglets cochés. (Parce que ça fait plus sens qu’un ou qui semble peut utile a priori)
|
|
|
Filtre des templates: En l’état si on coche templates ça affiche les templates qui correspondent au reste des filtres, donc si on coche templates et un type ça affiche les templates de ce type. Mais c’est pas clair dans l’interface
|
|
|
|
|
|
* Soit on change pour que Templates soit considéré comme un type d’objet
|
|
|
* -> conséquence: On affiche les templates de tous les types ou aucun
|
|
|
* oui ca signifie qu'on voit tout les templates quels qu'ils soient, ca veux dire voir des templates systeme dans user ou juste les templates d'un branche / type donne ?
|
|
|
* Non ça veut dire que dans systèmes si tu coches templates tu as tous les templates de systèmes, tu peux pas demander à filtrer juste les templates de serveurs par exemple. Mais ça n’affiche évidémment pas les templates user ou autres types pas listés.
|
|
|
* ok donc ca me va
|
|
|
* Ok ça permet de garder le style actuel.
|
|
|
* Soit on sépare le filtre visuellement pour que ce soit plus clair et on garde le fonctionnement actuel
|
|
|
* -> conséquence: On peut afficher les templates d’un certain type, mais on ne peut pas afficher les templates d’un type sans afficher le type. (donc si on affiche les templates user ou a les user avec, c’est bof je pense)
|
|
|
* en effet
|
|
|
* Soit on fait une case à cocher par type de template, mais dans systèmes ça va être ingérable
|
|
|
* Soit ?
|
|
|
|
|
|
Fait des ticket pour tout ces points avec les decisions et descriptions de ce qu'il y a a faire et le temps necessaire pour les realiser
|
|
|
|
|
|
Vers 15h00 ou des que tout les tickets sont fait faisons un reunion sur les formulaire et les dev condorcet
|
|
|
|