Création de ticket - entité

vincent.moittie · 2015-12-03 16:03:03

Bonjour

J'ai une arborescence simple d'entité : entité root contient l'entité A et l'entité B.

tous mes utilisateurs ont un profil self-service en récursif sur l'entité root.

J'ai deux groupe de technicien qui ne doivent pas connaître les ticket de l'autre groupe, ils ont leurs propres catégories associé à leur entité respective.

Est-il possible lors de la création d'un ticket de la part d'un utilisateur (sous l'entité root) de mapper automatiquement l'entité par défaut du ticket en fonction de la catégorie ?

Par exemple que s'il choisit la catégorie X de l'entité A, le ticket ne soit pas créer sous l'entité root mais sous l'entité A.

version 0.91 de GLPI

Last edited by vincent.moittie (2015-12-03 16:03:34)

LaDenrée · 2015-12-03 16:53:18

pour votre utilisation c'est plutot les groupe qu'il faudrait utiliser.
en général le demandeur est associé à une seule entité et les techniciens changent d'entité naviguent dans les entités en fonction des tickets.

si vous attribuez automatiquement les tickets à GroupeTech1 et GroupeTech2 et que les techs sont associés aux groupes autorisés et ont un profil TechDroitsLimités qui ne leur permet pas "voir tous les tickets" mais "voir les ticket des groupes" ils ne voient pas les tickets des autres groupes.

vincent.moittie · 2015-12-03 17:00:09

Je vais essayer, merci de votre réponse

vincent.moittie · 2015-12-04 14:43:58

Effectivement cela correspond à ce que je veux faire merci

nquiniou · 2016-01-08 12:08:26

Bonjour,

J'ai les mêmes configuration et besoin que vincent.moittie mais je ne souhaite pas utiliser les groupes.

Comment faire pour affecter un ticket à une entité enfant lorsqu'un utilisateur est rattachée à l'entité parente ?
Qu'est ce qui détermine le rattachement d'un ticket à une entité lors de la création ? Je n'ai rien trouvé dans le manuel à ce sujet.

Merci d'avance pour votre aide.

LaDenrée · 2016-01-08 12:16:27

bonjour,

@nquiniou : quelle version de GLPI
le demandeur doit appartenir au moins à l'entité du ticket (mais il peut aussi avoir des droits sur les autres entités).

je pense que si vous donnez un profil récursif au demandeur, vous pourrez choisir l'entité lors de la création de ticket après avoir choisi le demandeur.

sinon vous pouvez aussi définir l'entité enfant par défaut pour ce demandeur et le ticket sera créé dans l'entité par défaut.

nquiniou · 2016-01-08 15:26:44

Bonjour,

LaDenrée wrote:

@nquiniou : quelle version de GLPI

0.90.1

LaDenrée wrote:

je pense que si vous donnez un profil récursif au demandeur, vous pourrez choisir l'entité lors de la création de ticket après avoir choisi le demandeur.

Je ne vois pas comment l'entité peut-être changée une fois que le demandeur est défini.

LaDenrée wrote:

sinon vous pouvez aussi définir l'entité enfant par défaut pour ce demandeur et le ticket sera créé dans l'entité par défaut.

Cette solution marche mais je souhaite qu'un ticket puisse être créé dans trois entités au choix.

Pour information, l'architecture des entités est la suivante :

               Entité mère
                    |
                    |
-------------------------------------------
|                   |                     |
|                   |                     |
E1                  E2                    E3

La majorité des utilisateurs disposent d'un profil Self-Service en récursif sur l'entité mère. Le besoin : il faut qu'ils puissent ouvrir des tickets sur les trois entités de façon simple. D'où ma question : qu'est ce qui détermine le rattachement d'un ticket à une entité lors de la création ? (si vous avez la réponse, je suis preneur).

Mon architecture n'est peut-être pas correcte ;-)

LaDenrée · 2016-01-08 15:31:22

si le DEMANDEUR est dans l'entité même avec un profil récursif, quand vous mettez son nom dans "demandeur"
un dropdown avec les entités apparait sous l'adresse email.

nquiniou · 2016-01-08 15:42:29

C'est tout à fait vrai, je n'avais pas vu ce point de détail. Merci.

Cependant, comment faire lorsque c'est l'utilisateur (profil self-service, entité mère) qui ouvre un ticket via l'interface simplifiée ? Il ne peut pas sélectionner l'entité de destination (E1, E2 ou E3) et je ne souhaite pas lui affecter une entité par défaut.

nquiniou · 2016-01-08 16:46:43

J'ai obtenu une réponse à mes questions sur IRC :

08-01-2016 14:27 <nqb> Si quelqu'un à la réponse à cette question : qu'est
ce qui détermine le rattachement d'un ticket à une
entité lors de la création ?
08-01-2016 14:42 <orthagh> l'entité du créateur du ticket (à l'ouverture du
formulaire) puis la ou les entité(s) du
demandeur si il y a un changement avant création
08-01-2016 14:52 <nqb> ok orthagh et nous sommes d'accord qu'il n'est pas
possible de jouer sur ce comportement via des règles
?
08-01-2016 14:54 <orthagh> pour les tickets créé manuellement, non
08-01-2016 14:54 <orthagh> pour les ticket des collecteurs, si, via les
règles des collecteurs
08-01-2016 14:56 <nqb> ok, c'est bien ce que j'ai constaté. Une évolution
est prévue pour les tickets créé manuellement ?
Est-ce qu'on peut contourner ce comportement pour
les tickets créé manuellement ?
08-01-2016 14:57 <orthagh> non et non
08-01-2016 14:57 <orthagh> la raison est que les tickets doivent être
(normalement) visible par le demandeur
08-01-2016 14:57 <orthagh> après il est possible dans un second temps de
transférer ces tickets
08-01-2016 14:59 <nqb> Dans mon archi, les utilisateurs ont un profil
self-service récursif sur une entité mère de trois
autres entités.
08-01-2016 14:59 <nqb> Je souhaitais que lorsqu'ils ouvrent un ticket,
l'entité soit déduite d'une catégorie ou d'un autre
champ.
08-01-2016 15:00 <nqb> Dans ce cas, les tickets sont bien visibles pour le
demandeur.
08-01-2016 15:00 <orthagh> c'est possible pour un technicien qui créé un
ticket pour un self-service de faire facilement
ce transfert directement à la création
08-01-2016 15:01 <orthagh> au moment où il choisit le demandeur, le
formulaire se recharge, et une liste déroulante
de sélection de l'entité apparaît
08-01-2016 15:01 <orthagh> permettant de définir l'entité du ticket
08-01-2016 15:01 <nqb> tout à fait
08-01-2016 15:01 <orthagh> dans le cas de l'interface self-service
08-01-2016 15:01 <orthagh> la ticket est toujours créé dans l'entité active
de l'utilisateur
08-01-2016 15:01 <orthagh> le seul moyen est de changer de façon générale
d'entité
08-01-2016 15:02 <orthagh> sinon non pas de déduction d'entité à partir
d'une catégorie nativement
08-01-2016 15:02 <orthagh> le seul moyen serait de faire un plugin
08-01-2016 15:02 <nqb> ok
08-01-2016 15:03 <nqb> Dans ce cas, je vais réfléchir à une autre
organisation pour mes utilisateurs en self-service
08-01-2016 15:04 <nqb> Mais je vois pas bien comment faire pour qu'ils
puissent créér des tickets spécifiques à moins
qu'ils changent d'entité avant de créer le ticket
08-01-2016 15:05 <nqb> ce qui n'est pas très "user-friendly"
08-01-2016 15:06 <orthagh> je ne veux présumer de rien, mais il semblerait
que vous utilisiez les entités pour representer
autre chose que de l'organisation d'entreprise,
non ?
08-01-2016 15:07 <orthagh> si vous souhaitez orienter vos tickets vers des
compétences de traitement, les groupes sont plus
adaptés
08-01-2016 15:08 <Tsmr> bon j'ai trouver bug sur profiles
08-01-2016 15:08 <Tsmr> $val = $_SESSION['glpiactiveprofile'][$key];
08-01-2016 15:09 <Tsmr> mais des fois le tableau n'existe pas (exemple
typique des droits de plugins)
08-01-2016 15:09 <Tsmr> faut qu'on fasse un if
(isset($_SESSION['glpiactiveprofile'][$key])) {
avant
08-01-2016 15:09 <nqb> orthagh: les groupes ok mais tout en conservant un
cloisonnement étanche entre les tickets et les
éléments d'inventaire.
08-01-2016 15:09 <nqb> ?
08-01-2016 15:11 <orthagh> il est possible de limiter aux utiliseurs dans
leurs profils, la vue aux seuls tickets
attribués à leur groupe
08-01-2016 15:11 <orthagh> les éléments d'inventaire ne sont limité que par
les entités
08-01-2016 15:13 <nqb> D'accord
08-01-2016 15:14 <orthagh> je suis assez curieux de savoir comment il est
possible d'avoir les self-service en entité
racine et les techniciens dans les sous-entités
08-01-2016 15:14 <orthagh> le cas le plus courant est plutôt l'inverse
08-01-2016 15:14 <orthagh> ou bien d'avoir les techniciens au même niveau
que les demandeurs
08-01-2016 15:14 <nqb> J'ai sans doute fait une erreur dans mon
architecture d'entité
08-01-2016 15:14 <nqb> Mon architecture est la suivante
08-01-2016 15:15 <nqb> Nom organisation (entité mère)
08-01-2016 15:15 <nqb> |
08-01-2016 15:15 <nqb> |
08-01-2016 15:15 <nqb> -------------------------------------------
08-01-2016 15:15 <nqb> | | |
08-01-2016 15:15 <nqb> | | |
08-01-2016 15:15 <nqb> Service1 Service2 Service3
08-01-2016 15:16 <nqb> J'ai donc donné un profil self-service à mes
utilisateurs sur l'entité mère
08-01-2016 15:17 <nqb> Sur Service2 : j'ai un utilisateur avec un profil
"Supervisor"
08-01-2016 15:18 <nqb> Sur Service3 : idem que pour Service2
08-01-2016 15:18 <nqb> Ces services représentent des services de
l'organisation
08-01-2016 15:18 <orthagh> ok
08-01-2016 15:19 <nqb> Je souhaite que les tickets et éléments d'inventaire
de chaque "Service" soient étanches. Tout en
permettant aux utilisateurs self-service d'ouvrir
facilement des tickets sur les matériels des trois
entités.
08-01-2016 15:19 <nqb> Je n'affirme absolument pas que c'est la bonne
organisation :-)
08-01-2016 15:19 <orthagh> ok, c'est effectivement la le noeud du problème
08-01-2016 15:20 <nqb> oui pourtant c'est mon besoin
08-01-2016 15:21 <orthagh> je ne vois pas comment réconcilier"l'étanchéité"
des elements et que justement les utilisateurs
puissent voir tout les éléments d'inventaire
08-01-2016 15:21 <orthagh> les 2 besoins s'opposent
08-01-2016 15:21 <nqb> je n'étais pas été assez clair
08-01-2016 15:23 <nqb> Je ne veux pas que le "Supervisor" du Service2
puisse avoir accès aux éléments d'inventaire du
Service1. J'entends par accès une lecture des
caractéristiques des éléments d'inventaire.
08-01-2016 15:24 <orthagh> je n'ai pas de solution native donc
08-01-2016 15:25 <orthagh> soit il faut faire une croix sur l'un des 2
besoins
08-01-2016 15:25 <orthagh> soit il faut développer un plugin qui se
chargera de faire le transfert spécifique
d'entité
08-01-2016 15:26 <orthagh> il est envisageable d'ajouter une action
transférer au règles métier pour les tickets
08-01-2016 15:26 <orthagh> ce serait facile en création
08-01-2016 15:26 <orthagh> a mon avis beaucoup moins en modification
08-01-2016 15:26 <nqb> vous faites allusion à la distinction
"ajouter/mettre à jour" ?
08-01-2016 15:27 <orthagh> exactement
08-01-2016 15:28 <nqb> D'accord. Donc si on dispose de cette action, mon
besoin peut être satisfait.
08-01-2016 15:28 <nqb> ?
08-01-2016 15:28 <orthagh> je pense que oui
08-01-2016 15:28 <orthagh> mais comme je le disais, ce n'est pas mineur
08-01-2016 15:29 <nqb> à cause du transfert
08-01-2016 15:29 <nqb> pourtant c'est bien fait pour le collecteur
08-01-2016 15:29 <orthagh> à la création seulement
08-01-2016 15:29 <orthagh>
08-01-2016 15:30 <nqb> Pour être sûr de bien comprendre, ajouter l'action
"Transférer" ou "Assigner l'entité X" dans les
règles métier est un changement majeur ?
08-01-2016 15:30 <orthagh> oui
08-01-2016 15:30 <orthagh> l'action Transférer n'est pas anodine
08-01-2016 15:31 <orthagh> il faut prendre en compte toutes les liaison
possibles
08-01-2016 15:31 <orthagh> et ne pas rendre indisponible des élements liés
au ticket transféré
08-01-2016 15:32 *** AnatomicJC NICK AnatomicJC_away
08-01-2016 15:32 <nqb> Malgré le fait qu'on le fasse déjà dans les "Règles
pour assigner un ticket créé via un collecteur de
courriels" ?
08-01-2016 15:33 <orthagh> oui
08-01-2016 15:33 <orthagh> parce que c'est fait en création
08-01-2016 15:33 <orthagh> et dans ce cas, tout les éléments qui découlent
du ticket prennent l'entité du ticket
08-01-2016 15:34 <orthagh> et via le collecteur, il n'est pas possible
d'affecter des éléments d'inventaire (et donc
avoir des incohérences d'entités)
08-01-2016 15:35 <nqb> D'accord. Donc ajouter l'action "Transférer" ou
"Assigner l'entité X" dans les règles métier *en
création est un changement majeur ?
08-01-2016 15:35 <orthagh> oui
08-01-2016 15:36 <nqb> je voulais mettre : "*en création* est un changement
mineur"
08-01-2016 15:36 <orthagh> comme pour votre suggestion d'hier, je vous
invite à l'ajouter au site dédiée, pour ne pas
l'oublier
08-01-2016 15:36 <orthagh> et d'autres acteurs (utilisateur ou dev)
pourront aussi y réagir
08-01-2016 15:36 <nqb> Tout à fait.
08-01-2016 15:36 <orthagh> et voir des façon de faire peut être plus simple
que moi
08-01-2016 15:36 <nqb> Oui.
08-01-2016 15:37 <orthagh> personnellement, je ne vois pas mieux
08-01-2016 15:37 <nqb> Merci pour votre temps et toutes ces informations
précieuses.
08-01-2016 15:37 <orthagh> je vous en prie

Forum GLPI-Project

Announcement

#1 2015-12-03 16:03:03

Création de ticket - entité

#2 2015-12-03 16:53:18

Re: Création de ticket - entité

#3 2015-12-03 17:00:09

Re: Création de ticket - entité

#4 2015-12-04 14:43:58

Re: Création de ticket - entité

#5 2016-01-08 12:08:26

Re: Création de ticket - entité

#6 2016-01-08 12:16:27

Re: Création de ticket - entité

#7 2016-01-08 15:26:44

Re: Création de ticket - entité

#8 2016-01-08 15:31:22

Re: Création de ticket - entité

#9 2016-01-08 15:42:29

Re: Création de ticket - entité

#10 2016-01-08 16:46:43

Re: Création de ticket - entité

Board footer