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

Version 5 (webmyster, 07/10/2013 02:29 PM) → Version 6/15 (moyo, 07/10/2013 02:43 PM)

h1. 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.

h1. 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.

h2. 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 ?

h2. 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.

MoYo ; je crois qu'au final je ne vois vraiment pas ce que tu proposes. Tu pourrai proposer une maquette même simpliste de ce que tu proposes ?
MoYo : une idée peut-être fausse de ce que je comprend. Au lieu de mettre add_document tu veux mettre comme clé d'action Document/add par exemple (action massive add de Document) ?
Web : J'ai ajouté un diff (pas à jour par rapport au tronc commun car j'ai commencé ce prototype la semaine dernière). Dans ce proto, seules les actions de mise à jours et les actions liées au lock sont actives. Mais l'idée générale est là.

_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@).

MoYo : normal on est pas aller jusqu'à proposer une action complète (c'est pour ca quelle s'appelle do_nothing d'ailleurs)

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@.

MoYo : oui dans l'architecture actuelle cela permettait simplement de centraliser le code. Car dans les moteurs de recherche on a pas accès à l'item Computer_Item. Cf. remarque plus haut sur l'intérêt d'une maquette je pense.

h2. 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 ?

MoYo : pourquoi pas. A voir avec une proposition concrète.

h2. Est-il possible de supprimer l'utilisation de checkitem ?

Avec le mécanisme proposé, je sens qu'il est possible de se passer de @checkitem@. En fait, j'ai du mal à comprendre son utilisation ...

MoYo : si on peut le supprimer tant mieux. L'intérêt est le suivant : pouvoir contrôler un autre objet pour savoir si on peut réaliser l'action.
Par exemple sur les NetworkPort, si on contrôle le droit standard on peut avoir le droit de modifier les ports réseaux globalement et on aura donc les modifs massives proposés pour tous les itemtypes qui ont des ports réseaux; Hors on peut avoir un itemtype pour lequel on a que le droit de lecture (et donc pas de modifs massives permises).