Permettre la gestion de plusieurs items pour les actions massives » History » Version 2

« Previous - Version 2/15 (diff) - Next » - Current version
moyo, 07/10/2013 01:43 PM


Permettre la gestion de plusieurs items pour les actions massives

En passant les items actifs à la fenêtre de choix des actions, on peut filtrer plus précisémment les actions à effectuer.

Par exemple, pour les liens élément<->composant, la modification 'update' n'est pas utile sur certains type de devices. Ainsi, si on ne coche que des Item_DeviceCase, on n'affiche que le "delete" et le "unaffect" dans la fenêtre modale.
De plus, lorsque l'on coche plusieurs types de devices, le update est spécifique alors que la suppression ou la désaffectation est commune. Par exemple, si on coche des processeurs et des mémoires, on pourrait choisir comment action :
  • Désaffectation des composants ;
  • Suppression des composants ;
  • Mise à jours de la mémoire ;
  • Mise à jours du processeur.

Cela serait beaucoup plus simple pour gérer la suite de l'affichage. En effet, pour la mise à jours, on a besoin de savoir exactement sur quel type d'objet on travail, pour connaître les champs disponibles. Alors que pour les deux autres actions, on peut l'appliquer à tous les types d'items.

Webmyster: personnellement, je trouve que la classe CommonDBTM est énorme (près de 5000 lignes de code). Je galère toujours pour retrouver ce que je recherche dedans. Donc, je propose de transférer tous les éléments génériques concernant les massives action dans une classe MassiveAction (showMassiveActionsParameters, executeMassiveActions, doMassiveActions, getAllMassiveActions ...). Après tout, on a besoin d'un objet item dans les méthodes de gestion des MassiveActions. Mais ce n'est pas spécifique à un item particulier. Les méthodes spécifiques (showSpecificMassiveActionsParameters, doSpecificMassiveActions, getForbiddenStandardMassiveAction, getSpecificMassiveActions ...) resteraient dans la classe CommonDBTM.

Pour dissocier les actions "communes" des actions "spécifiques", je propose d'ajouter une méthode MassiveAction::getCommonActions qui renverrait un tableau des actions qui sont communes. Par définition, les actions "communes" sont au moins définies dans la classe MassiveAction. Donc, il me semble plus simple de les indiquer plutôt que d'indiquer celles qui sont spécifiques. Cela est invalidé par la section Comment gérer les actions spécifiques ?' ci-dessous.

Suppression de itemtype ?

Après réflexion (et quelques tests), je me rend compte que le champs itemtype, défini dans Html::showMassiveActions() n'est plus utile dans tout le traitement des actions massives. En effet, ce champs itemtype serait dynamique avec la liste des champs choisis. Et certaines actions spécifiques, ou non, n'en ont l'utilité qu'au dernier moment.

Ce champs me semble même problèmatique : quel itemtype définir si nous proposons les actions massives pour une recherche globale (front/allassets.php) avec des Printer, des Computer ... dans le résultat ?

MoYo : Il me semble qu'on peut effectivement le virer en basculant sur la nouvelle architecture.

Qu'en est-il des actions qui en ont besoin ?

Certains actions ont besoin de savoir à quel type d'item elles doivent s'appliquer, notamment update (pour savoir quels sont les champs modifiables). Lorsque l'utilisateur a coché des cases de nature différente, l'action peut afficher un dropdown de choix de l'itemtype (affichage centralisé dans la classe MassiveActions). Dès que l'itemtype est défini ou si l'utilisateur n'a coché qu'un seul type d'item, elle peut afficher ses informations spécifiques (liste des champs à modifier pour l'action update).

MoYo : Là j'ai quelques doutes. On peut aussi simplement proposer les entrées "Mise à jours de la mémoire / Mise à jours du processeur." comme tu l'indiques au début ?

Comment gérer les actions spécifiques ?

Lorsqu'il s'agit d'actions spécifiques (ie. non gérées par la classe MassiveActions), nous pourrions associer une classe à chaque action. Cette classe contiendrait les méthodes showSpecificMassiveActionsParameters et doSpecificMassiveActions.
Par exemple, les actions add_document et remove_document renverraient la classe Document, toutes les actions unlock_* (réunies sous la même appellation unlock) concerneraient la classe Lock. On voit que certaines actions définies dans les méthodes communes showMassiveActionsParameters et executeMassiveActions peuvent en sortir pour intégrer d'autres classes plus appropriées.
Au passage, on pourrait unifier le mécanisme pour les classes du coeur et celles des plugins (avec un Plugin::registerClass). Nous pouvons conserver le mécanisme actuel en parallèle de ce nouveau mécanisme.

aparté: le plugin example me semble invalide car il déclare une action do_nothing qui n'est pas interprétée comme l'action d'un plugin (cf. test ligne 3566 de inc/commondbtm.class.php).

Après avoir essayer de gratter un peu, je me suis rendu que dans certaines classes, certaines actions n'étaient de que des proxy vers les vraies classes. Par exemple, la vraie classe gérant connect et disconnect est Computer_Item, les autres classes (Phone, Printer ...) n'ont défini doSpecificMassiveActions que pour faire un proxy vers Computer_Item.

Passage des méthodes en static ?

Les méthodes de la classe MassiveActions doivent être static. Ne pourrions-nous pas faire pareille pour les méthodes spécifiques (showSpecificMassiveActionsParameters et doSpecificMassiveActions) dans les différentes classes ?

svn.diff Magnifier - Fichier SVN contenant un premier prototype relativement fonctionnel (88.5 KB) webmyster, 07/10/2013 02:17 PM