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.
- Tsmr on masque les statuts de résolution et de clôture des tickets ?
- MoYo si on affiche l'info assez explicitement. A l'utilisateur de faire attention aussi.
- Tsmr : Le mieux serait d'interdire de fermer le ticket
-> 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
- Tsmr : via le moteur de règles métier, oui cela pourrait être intéressant. (en 0.80 ?)
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
- 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 :
- Liste des validations : utilisation d'un filtre par approbateur ?
- Moyo : je ne comprend pas la question
- Tsmr : lié à la question précédente
- Moyo : je ne comprend pas la question
- Droit : approve_ticket : r/w ? ou 0/1 ?
- Moyo : 0/1 a priori car on peut le comprendre : "a la capacité d'approuver"
- 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)
- 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
- Tsmr : Problème : le dropdownUsers de sélection de l'approbateur coté helpdesk est non fonctionnel. le checkcentralaccess empêche de l'utiliser :/
- MoYo : ca peux être la même page que pour central au final.
- 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 ?
- MoYo mais quelle différence fait tu entre r et w ?
- 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 ?