You are not logged in.
Bonjour,
Dans le Plug-in comportement : Est-ce qu'il serait possible de rendre obligatoire la désignation d’un technicien.
Merci,
Offline
C'est possible dans le gabarit par défaut des tickets en 0.83
Xavier Caillaud
Blog GLPI Infotel
Offline
Oui effectivement, mais je souhaiterais que ce soit dynamique.
Dans les paramètres du gabarit, il est possible de désigner un agent en particulier.
CE que je souhaiterais ici, c'est lorsque l'intervenant va saisir sa solution dans le ticket, qu'il y ait un message qu'il l'avertisse que tant qu'un technicien ne se sera pas attribué le ticket qu'il ne pourra pas saisir cette solution..
Offline
rendre obligatoire la désignation d’un technicien => OUI avec les gabarits de ticket
Offline
Dans les paramètres du gabarit, il est possible de désigner un agent en particulier.
.
Il est aussi possible de rendre ce champ obligatoire
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
bonjour,
Effectivement, il possible au niveau du gabarit du ticket de rendre obligatoire la saisie d'un technicien. Mais dans ce cas, la saisie est obligatoire au moment de la saisie du ticket sur l'interface complète.
Plus précisément : soit un ticket crée par un demandeur sur une interface simple. Le ticket est attribué automatiquement à un groupe d'intervenants.
Je souhaiterais qu'un intervenant ne puisse pas saisir de solution par exemple tant qu'au moins un intervenant ne se soit pas désigné comme prenant en charge le ticket.
Offline
Bonjour,
Je me permets de rebondir sur ce vieux post car j'ai le même souci, certains techniciens ne s'assignent pas le ticket avant de soumettre une solution..
Pourrait-on imaginer rajouter une fonctionnalité au plugin Behaviors/Comportements du type : "Technicien obligatoire pour résoudre/fermer un ticket"
Merci
Prod : GLPI 0.84.8
Dev : GLPI 0.85.4
Offline
Ticket ouvert sur la forge du plugin : https://forge.indepnet.net/issues/5381
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour Yllen,
Merci pour la prise en compte de cette demande.
Je ne suis pas trop calé en dev, mais si cela peut vous aider, voici une petite idée du code à implémenter ?
Dans le fichier config.class.php :
static function install(Migration $mig) {
global $DB;
$table = 'glpi_plugin_behaviors_configs';
if (!TableExists($table)) { //not installed
$query = "CREATE TABLE `". $table."`(
`id` int(11) NOT NULL,
`use_requester_item_group` tinyint(1) NOT NULL default '0',
`use_requester_user_group` tinyint(1) NOT NULL default '0',
`is_ticketsolutiontype_mandatory` tinyint(1) NOT NULL default '0',
`is_ticketsolution_mandatory` tinyint(1) NOT NULL default '0',
`is_ticketcategory_mandatory` tinyint(1) NOT NULL default '0',
`is_ticketrealtime_mandatory` tinyint(1) NOT NULL default '0',
`is_requester_mandatory` tinyint(1) NOT NULL default '0',
`is_technician_mandatory` tinyint(1) NOT NULL default '0',
`is_ticketdate_locked` tinyint(1) NOT NULL default '0',
`use_assign_user_group` tinyint(1) NOT NULL default '0',
`tickets_id_format` VARCHAR(15) NULL,
`is_problemsolutiontype_mandatory` tinyint(1) NOT NULL default '0',
`remove_from_ocs` tinyint(1) NOT NULL default '0',
`add_notif` tinyint(1) NOT NULL default '0',
`use_lock` tinyint(1) NOT NULL default '0',
`single_tech_mode` int(11) NOT NULL default '0',
`date_mod` datetime default NULL,
`comment` text,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci";
$DB->queryOrDie($query, __('Error in creating glpi_plugin_behaviors_configs', 'behaviors').
"<br>".$DB->error());
$query = "INSERT INTO `$table`
(id, date_mod)
VALUES (1, NOW())";
$DB->queryOrDie($query, __('Error during update glpi_plugin_behaviors_configs', 'behaviors').
"<br>" . $DB->error());
} else {
// Upgrade
$mig->addField($table, 'tickets_id_format', 'string');
$mig->addField($table, 'remove_from_ocs', 'bool');
$mig->addField($table, 'is_requester_mandatory', 'bool');
// version 0.78.0 - feature #2801 Forbid change of ticket's creation date
$mig->addField($table, 'is_ticketdate_locked', 'bool');
// Version 0.80.0 - set_use_date_on_state now handle in GLPI
$mig->dropField($table, 'set_use_date_on_state');
// Version 0.80.4 - feature #3171 additional notifications
$mig->addField($table, 'add_notif', 'bool');
// Version 0.83.0 - groups now have is_requester and is_assign attribute
$mig->dropField($table, 'sql_user_group_filter');
$mig->dropField($table, 'sql_tech_group_filter');
// Version 0.83.1 - prevent update on ticket updated by another user
$mig->addField($table, 'use_lock', 'bool');
// Version 0.83.4 - single tech/group #3857
$mig->addField($table, 'single_tech_mode', 'integer');
// Version 0.84.2 - solution description mandatory #2803
$mig->addField($table, 'is_ticketsolution_mandatory', 'bool');
//- ticket category mandatory #3738
$mig->addField($table, 'is_ticketcategory_mandatory', 'bool');
//- solution type mandatory for a problem #5048
$mig->addField($table, 'is_problemsolutiontype_mandatory', 'bool');
//- ticket technician mandatory #5381
$mig->addField($table, 'is_technician_mandatory', 'bool');
}
return true;
}
(...)
//ticket technician mandatory - feature #5381
echo "<tr class='tab_bg_1'>";
echo "<td>".__('Technician is mandatory before ticket is solved/closed', 'behaviors')."</td><td>";
Dropdown::showYesNo("is_technician_mandatory",
$config->fields['is_technician_mandatory']);
echo "</td></tr>";
Dans le fichier ticket.class.php :
static function beforeUpdate(Ticket $ticket) {
(...)
$cat = (isset($ticket->input['itilcategories_id'])
? $ticket->input['itilcategories_id']
: $ticket->fields['itilcategories_id']);
//ticket technician mandatory - feature #5381
$tec = PluginBehaviorsTechnician::isTechnicianAssigned($ticket->input['id']);
(...)
if ($config->getField('is_ticketcategory_mandatory')) {
if (!$cat) {
unset($ticket->input['status']);
unset($ticket->input['solution']);
unset($ticket->input['solutiontypes_id']);
Session::addMessageAfterRedirect(__("You cannot close a ticket without ticket's category",
'behaviors'), true, ERROR);
}
}
//ticket technician mandatory - feature #5381
if ($config->getField('is_technician_mandatory')) {
if ($tec == 0) {
unset($ticket->input['status']);
unset($ticket->input['solution']);
unset($ticket->input['solutiontypes_id']);
Session::addMessageAfterRedirect(__("You cannot close a ticket without a technician assigned",
'behaviors'), true, ERROR);
}
}
Et dans un nouveau fichier technician.class.php :
class PluginBehaviorsTechnician {
static private function isTechnicianAssigned ($id) {
global $DB;
//Est-ce qu'un technicien est assigné au ticket ?
$query = "SELECT users_id
FROM glpi_tickets_users
WHERE tickets_id = '".$id."'
AND type = '2'";
$res = $DB->query($query);
$id_tec = $DB->fetch_assoc($res);
if (!$id_tec) {
return 0;
}
else {
return 1;
}
}
}
Sans oublier de rajouter la traduction du nouveau texte dans le fichier fr_FR.po.
Soyez indulgent si mon code est foireux
Offline
Je suis toujours indulgente avec les gens qui proposent des patchs.
Juste une remarque pour vous permettre d'évoluer encore en code GLPI : pourquoi créer une class PluginBehaviorsTechnician alors que la class qui liste les liens tickets_users existe déjà ? De plus lorsque vous ajoutez ou supprimer un technicien, vous ne modifiez pas le ticket mais le lien entre le ticket et les utilisateurs. Donc le contrôle de présence du technicien doit ce faire à la modification de la liaison et aussi à la création du ticket.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
C'est vrai, j'aurais pu (dû ?) déclarer ma fonction dans la classe ticket_user, je n'y ai pas pensé du tout car j'ai pris comme base le fichier user.class.php et intuitivement pensé à créer une classe technician sur ce modèle..
Merci de la remarque, je ferai plus attention la prochaine fois
En fait, le problème que je rencontre est le suivant : les techniciens oublient de s'assigner les tickets avant de proposer une solution. Le souci est que lorsque l'on veut faire des stats, la charge de travail de chacun est plus ou moins faussé du fait de leur non-assignation au ticket.
C'est pour cela que je ne veux faire le contrôle de la présence d'un technicien que lorsqu'un ticket passe au statut résolu (comme pour la vérification de l'assignation d'une catégorie).
Il n'est pas important pour moi de vérifier si un technicien est assigné à la création du ticket (car nous fonctionnons principalement avec un collecteur).
Offline
Modification effectuée dans la version 0.90 du plugin qui est égtalement compatible GLPI 0.90.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline