History

Il est nécessaire également d'envisager la mise en place d'un workflow simplifié d'approbation : Action "Soumettre à approbation" pour les tickets.
Envoi d'une demande d'approbation à un utilisateur. (cf Plugin validation).

Nelly : ok retenu.

  • Onglet validation / approbation : OK Fait
  • Demande de validation + commentaire + sélection de la personne qui doit valider : OK Fait
  • Envoi de notification pour la validation, redirect vers la page de validation (lien dans mail) : OK Fait
  • Dans l'onglet validation coté personne qui valide, oui / non + commentaire => notification de la décision (Nouvel évènement à ajouter à la liste des notifications) : OK Fait
  • Ajout d'un droit "approbation" (dans la partie assistance) : OK Fait
  • Ajout des tickets en attente de validations dans la partie centrale du valideur (en rapport avec le droit définit ci-dessus) ou "aucun tickets à valider". : OK Fait
    • Coté Helpdesk : liste simplifiée des tickets en attente de validation de sa part
    • Coté console centrale : accès à la liste complète des validations (par contre il ne veut que valider les siens)
  • Ajout de 3 états pour chaque demande d'approbation : en attente d'approbation, approuvé, non approuvé : OK Fait
  • Création d'une nouvelle table (ID ticket,ID demandeur, ID valideur, commentaire demande, commentaire décision, décision (oui/non), date demande, date décision) : OK Fait
    • Champ decision inutile
  • Tracage historique : OK Fait
  • Réfléchir : demande sans réponse? quoi faire et comment le gérer? suppression d'une demande en attente?
    • Tsmr : Pour l'instant rien (vu avec Moyo) - avoir pour une tache cron ensuite, comme l'approbation de solution

Questions en suspens

Récapitulatif de droits :

interface Faire une demande de validation valider un ticket supprimer une demande de validation voir la liste des validations sur le ticket voir la liste des validations (Menu)
helpdesk create_validation (1) + droit sur ses tickets validate_ticket (1) + être l'approbateur désigné du ticket Pas possible *validate_ticket (1) + être l'approbateur désigné du ticket (pour voir les autres validations du ticket) Revision r10863 * accès à la liste de ses demandes de validations
console centrale create_validation (1) + droit sur ses tickets validate_ticket (1) + être l'approbateur désigné du ticket * haveRight('create_validation', 1) or (haveRight('update_ticket', 1) && haveRight('show_all_ticket', 1)) ? * *validate_ticket (1) + être l'approbateur désigné du ticket (pour voir les autres validations du ticket) Revision r10863 * accès à la liste de toutes les demandes de validations
  • Moyo : quelle contrainte met t'on pendant que le ticket est en attente de validation ? aucune ?
    • Tsmr : Le mieux serait d'interdire de fermer le ticket
      • MoYo si on affiche l'info assez explicitement. A l'utilisateur de faire attention aussi.
        • Tsmr on masque les statuts de résolution et de clôture des tickets ?
          • MoYo Pas besoin : Avec un affichage clair de l'état de validation dans le formulaire principal ca devrait sûrement suffire.

-> Exemple : demandes de validation : 2 (1 acceptée / 1 en attente)
Couleur de fond : si au moins un refus : rouge
Couleur de fond : si au moins un en attente : orange
Couleur de fond : si tout Ok vert

  • Moyo : a t'on le moyen de faire des demandes de validation automatique (suivant catégorie / groupe demandeur)? peut-être à voir pour plus tard
    • Tsmr : via le moteur de règles métier, oui cela pourrait être intéressant. (en 0.80 ?)
      • MoYo : en 0.78 si tu penses que ca peux être jouable. Sinon pour plus tard.
      • Walid : règles métiers ou pb pas rendre une catégorie du helpdesk à approbation obligatoire ? Sur la partie moteur, ça doit pas être méchant à faire

Remarques

  • Remi : sur la liste des approbations dans les tickets => il manque un lien vers l'approbation : OK Fait
  • Remi : sur la liste des approbations dans les tickets : Approbateur => lien vers la fiche de l'utilisateur : OK Fait
  • Remi : sur la fiche d'une approbation => t'as pas les onglets et la navigation -> utiliser une CommonDBChild : OK Fait
  • Remi : sur la fiche d'une approbation => afficher Demandeur ticket et Demandeur de l'approbation : OK Fait
  • Remi : sur la liste (Assistance / Approbation), ce serait sympa d'avoir une action massive d'approbation : OK Fait
  • Remi : pour les notifs => il faudrait pas 2 notifs ? (demande d'approbation ET réponse) et/ou des destinataires dédiés : déplacement dans ticketvalidationtarget.class.php ?
  • Remi : Est-ce logique de pouvoir demander une approbation sur un ticket clôt ? (voir résolu) : OK Fait
  • Remi : on peut pas créer de demande si l'utilisateur a pas de mail -> mettre juste un warning : OK Fait
  • Remi : la liste des "approbateur" ne me semble pas filtrer sur les utilisateurs ayant le droit d'approbation : OK Fait
  • Remi : il est possible de refuser sans mettre de commentaires.... pas forcément terrible : OK Fait

Tsmr - Table cible (si ca vous convient)

DROP TABLE IF EXISTS `glpi_ticketvalidations`;
CREATE TABLE `glpi_ticketvalidations` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(255) collate utf8_unicode_ci default NULL,
  `entities_id` int(11) NOT NULL default '0',
  `users_id` int(11) NOT NULL default '0',
  `tickets_id` int(11) NOT NULL default '0',
  `users_id_approval` int(11) NOT NULL default '0',
  `comment_submission` text collate utf8_unicode_ci,
  `comment_approval` text collate utf8_unicode_ci,
  `status` varchar(255) collate utf8_unicode_ci default 'waiting',
  `submission_date` datetime default NULL,
  `approval_date` datetime default NULL,
  `is_deleted` tinyint(1) NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `name` (`name`),
  KEY `entities_id` (`entities_id`),
  KEY `is_deleted` (`is_deleted`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Réponses

  • le champ décision (oui/non) a t-il vraiment un intérêt ? le statut (en attente d'approbation, approuvé, non approuvé) permet de connaitre l'état de la validation ?
    • Moyo : effectivement ca fait doublon. Pour le champ name je ne vois pas l'intérêt non plus.
  • Moyo : avec submission_date et approval_date est-ce nécessaire d'avoir date_mod ?
    • Tsmr : effectivement : pas besoin
  • Tsmr : Tracage historique ou ajout de suivi ? car cela envoie des emails donc c'est un lien avec l'utilisateur final.
    • MoYo : je dirais uniquement historique. Le demandeur devrait juste avoir une info minimale sur le fait que le ticket est en cours d'approbation par x ou y.
      • Tsmr : OK

Tsmr :

  • Liste des validations : utilisation d'un filtre par approbateur ?
    • Moyo : je ne comprend pas la question
      • Tsmr : lié à la question précédente
  • Droit : approve_ticket : r/w ? ou 0/1 ?
    • Moyo : 0/1 a priori car on peut le comprendre : "a la capacité d'approuver"
Liste des solutions
- 2 droits différents en 0/1 ? : OK Choisi
  • Faire une demande de validation (1 = accès au formulaire de demande)
  • Valider une demande (1 = accès a la liste des validations (coté helpdesk - liste sommaire - coté console centrale, Search::Show)
- 1 droit en r/w :
  • r : Faire une demande de validation (1 = accès au formulaire de demande coté console centrale)
  • w : Valider une demande (1 = accès a la liste des validations)
  • Peut-on valider : approuver un ticket coté helpdesk ?
    • MoYo : Dans la logique je dirais oui. Ca repose encore la question de l'uniformisation des interfaces.
    • Tsmr : Oui donc il faut une interface permettant de lister les validations en cours
      • MoYo : ca peux être la même page que pour central au final.
        • Tsmr : Problème : le dropdownUsers de sélection de l'approbateur coté helpdesk est non fonctionnel. le checkcentralaccess empêche de l'utiliser :/
          • Tsmr Pas de droit de faire de demande d'approbation coté helpdesk : OK Fait
  • Moyo : a quoi sert le champ is_deleted ?
    • Tsmr : Concernant is_deleted / name / filtre par approbateur et le droit : En fait dans le plugin validation, quand a le droit d'approbation, tu as accès à la liste des validations en attente / validé / refusé qui te sont affectés (d'ou le besoin du droit r/w). Utilise t'on le même système ? listons-nous les validations ?
      • MoYo mais quelle différence fait tu entre r et w ?
        • Tsmr Si on utilise un Search::show('TicketValidation'); y en a besoin pour pour le canview / cancreate, non ? a moins de ne pas utiliser Search::show et d'utiliser une interface dédiée basée sur un 0/1 ?