You are not logged in.
Pages: 1
Topic closed
Bonjour,
Lorsque je créé un ticket je suis par défaut dans le champs "Attribué à".
Ne voulant pas me l'attribuer, je me supprime du champs à la création du ticket et je sauvegarde.
Mais mon adresse mail est restée dans le champs et je ne peux plus la supprimer
=> Message "L'action que vous avez réalisée n'est pas autorisée."
Apparemment lors de la suppression de l'utilisateur (Créateur) du champs "Attribué à" à la création d'un ticket son adresse mail ne se supprime pas et reste à la sauvegarde.
Version GLPI utilisée: 9.5.7
Offline
Je ne reproduis pas le problème.
Si dans assigné a je remplace mon nom par ----, mon mail se supprime et n'est pas enregistré.
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
J'ai reproduis le problème 2 fois. GLPI Prod et Test en version 0.90.1
Version GLPI utilisée: 9.5.7
Offline
up
Version GLPI utilisée: 9.5.7
Offline
up
Version GLPI utilisée: 9.5.7
Offline
Vous avez des erreurs dans les logs de GLPI ?
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
J'ai refait des tests et toujours le même problème.
Lors de la création d'un ticket à la suppression de l'utilisateur attribué par défaut, l'adresse mail ne se supprime pas et si on enregistre impossible de la supprimer par la suite (sauf en base)
Version GLPI utilisée: 9.5.7
Offline
Avez vous essayé en version 0.90.2 ?
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
Je reviens vers vous car le problème se produit aussi en version 0.90.3 mais aléatoirement
Version GLPI utilisée: 9.5.7
Offline
et en 0.90.5, vous avez toujours le problème ?
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
Je n'ai pas encore effectué la mise à jour en 0.90.5
Je teste dès que celle-ci est faite.
Version GLPI utilisée: 9.5.7
Offline
Bonjour,
Je serais très intéressé par une solution car j'ai le même problème lors de la saisie en tant qu'admin.
Offline
Même problème en 0.90.5
Version GLPI utilisée: 9.5.7
Offline
Bonjour,
J'ai exactement le même problème suite à la mise à jour de GLPI en 0.90.5.
Merci d'avance.
Offline
Bonjour,
J'arrive à reproduire le bug, mais pour cela il faut absolument avoir modifier un champ qui recharge le ticket (comme la catégorie, le demandeur, ...) et ne pas s'être enlever de "attribué à" avant.
D'ailleurs j'irais même plus loin. Si on attribue le ticket à une personne et que l'on modifie un champ qui recharge le ticket. Si on enléve la personne "attribué à" son adresse email reste visible sur l'interface.
Je vais donner plusieurs exemple afin d'aider (malheureusement je ne vais pas pouvoir me pencher sur le code pour aider avant octobre).
Exemple 1 :
Avec dans "configuration > générale > valeur(s) par défaut", dans la partie "Assistance" on a "Pré-sélection comme technicien lors de la création de ticket" à "Non"
Je commence par choisir un technicien dans "Attribué à" (la page se recharge et l'adresse email apparaît)
Ensuite je mets une catégorie (la page se recharge)
Ensuite on enlève le technicien
A partir de ce moment, l'adresse email reste figé tant que l'on ne met pas un nouveau technicien
Exemple 2 :
Avec dans "configuration > générale > valeur(s) par défaut", dans la partie "Assistance" on a "Pré-sélection comme technicien lors de la création de ticket" à "Oui"
Je mets un demandeur (la page se recharge)
Ensuite on enlève le technicien (donc nous même)
A partir de ce moment, l'adresse email reste figé tant que l'on ne met pas un nouveau technicien
Last edited by kevinG (2016-09-01 09:07:58)
Version en production GLPI 9.4.5 - Agent FI 2.5
Version en production Fusion Inventory 9.4+2.4
Version PHP 7.2.16
Zend Engine v3.2.0 - Zend OPcache v7.2.16
Offline
Bonjour,
Alors comme promis je me suis penché sur le problème.
Donc le problème vient de l'envoi des valeurs par la méthode $_POST par défaut lors du rechargement de la page après modification d'une liste déroulante. Dedans on conserve systématiquement l'adresse email.
Je n'ai pas réussi à trouver à quel moment on passe les variables en paramètres mais j'ai une solution qui réinitialise l'adresse email.
Je pense qu'il faudrait traiter l'erreur à l'envoi des paramètres lors du rechargement mais en attendant et pour ceux que cela intéresse voici ma solution.
Dans le fichier "commonitilobject.class.php" dans le répertoire "..\GLPI\inc\" :
Modification des lignes 3413 à 3416 :
if (isset($options["_users_id_".$typename."_notif"]['alternative_email'])) {
$paramscomment['alternative_email']
= $options["_users_id_".$typename."_notif"]['alternative_email'];
}
Par :
if (isset($options["_users_id_".$typename."_notif"]['alternative_email'])) {
if($options["_users_id_".$typename] == 0){
$paramscomment['alternative_email'] = "";
}
else{
$paramscomment['alternative_email']
= $options["_users_id_".$typename."_notif"]['alternative_email'];
}
}
Ajout des lignes 3414 à 3417 et 3420.
Explication :
Je vérifie si l'on récupère l'ID de l'utilisateur.
Si c'est le cas, on fait le traitement normal sinon on dit que l'adresse email est vide comme lors de l'ouverture de la création d'un ticket.
Version en production GLPI 9.4.5 - Agent FI 2.5
Version en production Fusion Inventory 9.4+2.4
Version PHP 7.2.16
Zend Engine v3.2.0 - Zend OPcache v7.2.16
Offline
Je n'ai pas testé mais cela s'applique également à la version 9.1 ?
Plateforme : Linux...
Version GLPI : 9.5.6 (PROD) / 9.5.7 (TEST)
Plugins activés : Dashboard
Offline
Je n'ai pas la version 9.1 donc je ne peux pas tester.
Mais je viens de télécharger la version pour voir le fichier php est apparemment celui-ci ressemble à celui de la version 0.90.5, vu que les lignes sont exactes et le code identique (uniquement pour les lignes 3413 à 3416)
A tester , mais par précaution faire une copie du fichier avant de le modifier.
Ainsi si cela bug, le retour en arrière est possible et rapide en remettant la copie.
Last edited by kevinG (2016-09-28 15:31:04)
Version en production GLPI 9.4.5 - Agent FI 2.5
Version en production Fusion Inventory 9.4+2.4
Version PHP 7.2.16
Zend Engine v3.2.0 - Zend OPcache v7.2.16
Offline
Je ne comprend pas vos explications.
Pour supprimer un technicien, vous ne modifiez pas la liste déroulante car il faut cliquer sur la croix à côté du nom.
Je viens de faire vos 2 exemples et je ne reproduis toujours pas.
Si le prends votre exemple 2 en détail.
Création d'un ticket avec uniquement une description (pré-sélection en tant que technicien)
Je valide la création du ticket. J'ajoute un demandeur. La page ne se recharge pas ; la modification est prise en compte uniquement à la validation du formulaire.
Vous n'utiliseriez pas des plugins, style Formcreator ?
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
Par sécurité, pour faire le test, j'ai désactivé la totalité de mes plugins.
Le bug existe toujours.
Euh quand vous dites
Je valide la création du ticket
Vous cliquez sur le bouton "Ajouter" ?
La croix dont vous parlez n'existe que lorsque le ticket existe.
A ce moment la oui, il n'y a pas de bug.
Hors dans notre cas le ticket n'est pas encore créé.
Le bug se produit uniquement à ce moment la.
L'exemple 2 n'étant plus vrai pour la version 0.90.5, puisque si on a enlève le technicien, nous sommes à nouveau remis par défaut. Mais je pourrais en faire un paquet d'autre des exemples, vu que le bug est vrai pour tous les acteurs.
Détail, pour l'exemple 1, de toutes les étapes point par point (en espérant être plus clair) :
1 On clique sur "Assistance > Créer un ticket"
2 Dans la partie "Attribué à", on choisi un technicien
3 Dans la partie "Demandeur", on choisi un utilisateur
4 Dans la partie "Attribué à", on choisi "-----"
Maintenant l'adresse du technicien est figé sauf si on remet un techinicien.
5 On met une catégorie (celle-ci étant obligatoire, pour moi)
6 On clique sur le bouton "Ajouter"
La nouveau bug, un technicien avec juste une adresse email est ajouté et impossible de le supprimer sans passer par la bdd. Message d'erreur "Vous n'avez pas les droits requis pour réaliser cette action", je précise que j'ai la totalité des droits.
Voici les deux variables que j'ai en debug (qui pour moi son la cause du problème) pendant la création d'un ticket après l'étape 5 (j'ai mis en gras les anomalies):
QUERY_STRING => _target=/glpi/front/ticket.form.php&_itemtype=Ticket&_glpi_tab=Ticket$main&id=0&_date=29-09-2016%2008%3A42&date=2016-09-29%2008%3A42%3A22&_due_date=--%20&due_date=&slas_id=0&type=1&itilcategories_id=8&_users_id_requester=14&_users_id_requester_notif[use_notification][0]=1&_users_id_requester_notif[alternative_email][0]=JEAN-YVES.XXXXXXX%40domaine.fr&entities_id=0&_groups_id_requester=0&_users_id_observer[0]=0&_users_id_observer_notif[use_notification][0]=1&_users_id_observer_notif[alternative_email][0]=&_groups_id_observer=0&_users_id_assign=0&_users_id_assign_notif[use_notification][0]=1&_users_id_assign_notif[alternative_email][0]=kevin.XXXX%40domaine.fr&_groups_id_assign=0&_suppliers_id_assign=0&_suppliers_id_assign_notif[use_notification][0]=1&_suppliers_id_assign_notif[alternative_email][0]=&status=1&requesttypes_id=1&urgency=3&_add_validation=0&validatortype=0&impact=3&locations_id=0&priority=2&my_items=&itemtype=0&actiontime=0&name=&content=&_link[link]=1&_link[tickets_id_1]=0&_link[tickets_id_2]=0&_tickettemplates_id=1&_predefined_fields=W10%3D&_glpi_csrf_token=6ca41457665d8e1ee5bfc3fe8050f49e
REQUEST_URI => /glpi/ajax/common.tabs.php?_target=/glpi/front/ticket.form.php&_itemtype=Ticket&_glpi_tab=Ticket$main&id=0&_date=29-09-2016%2008%3A42&date=2016-09-29%2008%3A42%3A22&_due_date=--%20&due_date=&slas_id=0&type=1&itilcategories_id=8&_users_id_requester=14&_users_id_requester_notif[use_notification][0]=1&_users_id_requester_notif[alternative_email][0]=JEAN-YVES.XXXX%40domaine.fr&entities_id=0&_groups_id_requester=0&_users_id_observer[0]=0&_users_id_observer_notif[use_notification][0]=1&_users_id_observer_notif[alternative_email][0]=&_groups_id_observer=0&_users_id_assign=0&_users_id_assign_notif[use_notification][0]=1&_users_id_assign_notif[alternative_email][0]=kevin.XXXX%40domaine.fr&_groups_id_assign=0&_suppliers_id_assign=0&_suppliers_id_assign_notif[use_notification][0]=1&_suppliers_id_assign_notif[alternative_email][0]=&status=1&requesttypes_id=1&urgency=3&_add_validation=0&validatortype=0&impact=3&locations_id=0&priority=2&my_items=&itemtype=0&actiontime=0&name=&content=&_link[link]=1&_link[tickets_id_1]=0&_link[tickets_id_2]=0&_tickettemplates_id=1&_predefined_fields=W10%3D&_glpi_csrf_token=6ca41457665d8e1ee5bfc3fe8050f49e
Version en production GLPI 9.4.5 - Agent FI 2.5
Version en production Fusion Inventory 9.4+2.4
Version PHP 7.2.16
Zend Engine v3.2.0 - Zend OPcache v7.2.16
Offline
Je confirme le bug https://github.com/glpi-project/glpi/issues/1115
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,
Je suis sur la v9.1.1 et j'ai le bug
Offline
Comme indique dans mon précédent commit, la correction est prise en compte dans la 9.1.2
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
Pages: 1
Topic closed