But

L'idée à la base était de pouvoir définir des modèles de recherche, comme précisé dans le ticket #444
On peut généraliser le concept en réfléchissant à l'étendre à toutes les pages

Résumé - A valider

  • Une fonction qui appel l'affichage des boutons avec un type donné pour permettre les pretraitements (clean data, ajout data) du tableau passé ($_GET). On ajoutera par exemple un paramètre pour définir le module et l'action (cf. Framework) ainsi que reset_before, on supprimera dans les listes start.
  • Droits : possibilité de ne faire que du personnel dans un premier temps
    • Personnel : FK_users > 0 (FK_entities= -1)
    • Entité + recursive : FK_entities >= 0, recursive 0/1 (Fk_users = auteur)
  • Par défaut un bookmark n'est modifiable que par son auteur
  • Problématique de droits doit fournir des requêtes bizarres si on a pas le droit sur un élément.

Propositions

Disposer d'une table glpi_bookmark qui va stocker :
  • l'id de l'utilisateur
  • les paramètre GET de la page
  • le path de la page (la page appelée : computer.php, monitor.php, etc)
Les bookmarks sont personnels.
Question :
  • partage des bookmarks entre personnes ?
  • notion de bookmark public ?
  • gestion des entités ?

    MoYo : ca ne ressemble pas à la problématique du reminder ? Mais une solution initiale consisterait à ne faire que du personnel. L'extension sera possible dans un second temps.

    Remi : après en avoir discuter avec les utilisateurs, le partage semble particulièrement utile : l'administrateur construit une requête "tordue" qu'il partage pour que les techniciens traitent les machines concernées...
doum :
  • inclure la possibilité de mémoriser l'ordre de tri (champs "Trié par:") ? On m'a fait remarquer que pour certaines requêtes/vues il serait tres intéressant de pouvoir avoir un tri par défaut.
  • au niveau des bookmarks, possibilité de définir un bookmark par défaut pour une vue ? Qu'en pensez vous? Ex : pour ma vue Ordinateurs, afficher directement la vue avec la recherche "PC Fixe sur le domaine"

Problèmes éventuels

On ne peut pas, à l'heure actuelle faire un bookmark pour chaque page. Certaines nécessitent des paramètres passés en POST (voir en GEt et en POST).
Il faut prévoir un mécanisme en fonction du type pour pouvoir enrichir les informations (par exemple pour une requêtes du moteur il faut ajouter le param GET reset_before).

MoYo :
effectivement c'est une situation non standardisée encore. Il faudrait réfléchir et poser complètement la direction et vers quoi on tend en terme de framework / conventions.
Une idée assez simple de séparation des mécanismes : GET : propriétés d'afichages / POST : actions. Ca serait assez rapide de tendre vers cela.
Pour l'enrichissement il suffirait de typer les bookmarks pour y réaliser des actions spéciales.
Exemple pour le moteur de recherche : ajouter reset_before mais également supprimer certaines variables inutiles : start...
A voir si ces actions se réalisent au moment de la sauvegarde ou au moment de l'appel du bookmark. Il y a des avantages et des inconvénients dans les 2 cas.

Remi : pourquoi ne pas laisser à la page le boulot. Si elle veut pourvoir être enregistrée, elle positionne une variable globale contenant l'URL d'appel.

Walid : je propose un tableau de type de page (recherche, etc). Dans chaque page qui peut être bookmarkée, on rajoute une variable en post du type bookmark=type de page (comme ça on sait quel type de page c'est) et on peut l'enregistrer. Lors de l'enregistrement on fait une fonction qui prend en param le type de page, et qui, en fonction de celui-ci ajoute ou supprimer des params (ajout de reset_before, suppression de start, etc).

Cas d'utilisation

A noter ici les cas d'utilisation des bookmarks que l'on peut rescenser.