You are not logged in.
Bonjour,
Je cherche à mettre en place une organisation multi services et j'ai du mal à comprendre le fonctionnement entre les tickets, les profils et les entités
J'ai une société et plusieurs services amenés à gérés des incidents, par exemple j'ai le service RH qui gère des tickets, mais les autres services ne doivent pas voir ces tickets
Mes utilisateurs doivent tous pouvoir ouvrir tous les ticket, mais ces mêmes utilisateurs peuvent être tech sur certaines catégories.
Merci pour vos éclaircissements
Offline
Le découpage des services en sous-entités peut être une solution afin de compartimenter les tickets entre service.
Les profils sont multi-entités puisqu'il sont crées et gérés à partir de l'entité racine.
En revanche l'affectation d'un profil à un utilisateur se fait par entité. Ainsi, l'utilisateur ABC peut être user sur l'entité racine et admin sur l'entité RH.
En fonction du profil choisit il bascule automatiquement sur l'entité sur laquelle il a des droits.
Pour l'affectation des tickets aux entités correspondantes, je pense qu'il faut jouer avec les gabarits de tickets et faire des gabarits (incident et demande) par entité (ou pas selon els besoins, puisqu'il y a des notions d'héritage).
Les notifications de ticket peuvent aussi être personnalisées par entité.
Quand tu dis "Mes utilisateurs doivent tous pouvoir ouvrir tous les ticket", ils ne peuvent voir QUE leurs tickets, pas ceux des autres utilisateurs !
Manger un castor, c'est sauver un arbre.
Quand on est mort, on ne sait pas qu'on est mort ; c'est pour les autres que c'est difficile. Quand on est con, c'est pareil !
Offline
la solution présentée par sico31 fonctionne mais elle oblige l'utilisateur demandeur à choisir son entité pour déposer le ticket dans la bonne entité ce n'est pas simple pour l'utilisateur (mais ça marche)
je préfère une gestion par groupe.
les techniciens qui gèrent les tickets avec un profil "voir les tickets attribué = oui, voir tous les tickets=non" et le reste identique à technicien
un groupe G_TechnicienRH qui contient les intervenants RH
un groupe G_TechnicienInfo qui contient les intervenants Info
les autres utilisateurs avec un profil self-service (voir mes tickets = oui)
ensuite vous faite attribuer automatiquement les demandes RH au groupe G_techniciensRH et idem pour info
ainsi les tech RH ne voient que les tickets qui leur sont attribués, les tech infos ne voient pas les tickets RH
et le demandeur vois ses tickets RH et infos
pour attribuer automatiquement il y a plusieurs solutions : règle métier, en fonction de la catégorie, en fonction du collecteur....
personnellement, je le fais avec le plugin formcreator : un formulaire demande RH(attribue à RH), un formulaire info (attribue à info), etc..
j'utilise le plugin formcreator , dans votre cas je creerait un formulaire "mes demandes RH", un formulaire "mes demandes informatique", etc... qui seraient
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
Je me rend compte que je vous avais pas remercié, mieux vaut tard
J'ai progressé depuis le temps est c'est effectivement ce que j'ai mis en place
Merci
la solution présentée par sico31 fonctionne mais elle oblige l'utilisateur demandeur à choisir son entité pour déposer le ticket dans la bonne entité ce n'est pas simple pour l'utilisateur (mais ça marche)
je préfère une gestion par groupe.
les techniciens qui gèrent les tickets avec un profil "voir les tickets attribué = oui, voir tous les tickets=non" et le reste identique à technicien
un groupe G_TechnicienRH qui contient les intervenants RH
un groupe G_TechnicienInfo qui contient les intervenants Infoles autres utilisateurs avec un profil self-service (voir mes tickets = oui)
ensuite vous faite attribuer automatiquement les demandes RH au groupe G_techniciensRH et idem pour info
ainsi les tech RH ne voient que les tickets qui leur sont attribués, les tech infos ne voient pas les tickets RH
et le demandeur vois ses tickets RH et infos
pour attribuer automatiquement il y a plusieurs solutions : règle métier, en fonction de la catégorie, en fonction du collecteur....
personnellement, je le fais avec le plugin formcreator : un formulaire demande RH(attribue à RH), un formulaire info (attribue à info), etc..j'utilise le plugin formcreator , dans votre cas je creerait un formulaire "mes demandes RH", un formulaire "mes demandes informatique", etc... qui seraient
Offline
Bonjour,
J'ai mis en place dans une VM des formulaires pour chaque service comme indiqué dans votre message. Problème, quand un self-service d'un service/entité A rempli un formulaire à destination d'un serivce/entité B, ce dernier peut accéder au ticket crée par le formulaire qui lui est attribué, modifier ses informations, répondre au ticket, etc, mais le demandeur self-service du service A ne peut pas voir le ticket, seulement le formulaire. Quand je clique sur le formulaire qu'il a rempli, j'ai les onglets Réponse au formulaire, Tickets et Tous. Dans Réponse au formulaire je peut bien voir les informations que j'ai mis dans mon formulaire, mais quand je vais dans l'onglet Ticket, il y'a tout d'abord un petit "1" (ce qui montre bien qu'un ticket a été crée) et il est écrit "Pas de ticket trouvé".
Si je comprends bien, le demandeur self-service ne peux PAS accéder au ticket crée par son formulaire si le destinataire du formulaire n'appartient PAS à la même entité que le demandeur. C'est très embêtant.
Comment puis-je accéder à mon ticket et à son suivi? Est-ce qu'on ne peut vraiment pas communiquer entre entités sur GLPI?
Merci d'avance pour votre réponse, je reste bloquée.
la solution présentée par sico31 fonctionne mais elle oblige l'utilisateur demandeur à choisir son entité pour déposer le ticket dans la bonne entité ce n'est pas simple pour l'utilisateur (mais ça marche)
je préfère une gestion par groupe.
les techniciens qui gèrent les tickets avec un profil "voir les tickets attribué = oui, voir tous les tickets=non" et le reste identique à technicien
un groupe G_TechnicienRH qui contient les intervenants RH
un groupe G_TechnicienInfo qui contient les intervenants Infoles autres utilisateurs avec un profil self-service (voir mes tickets = oui)
ensuite vous faite attribuer automatiquement les demandes RH au groupe G_techniciensRH et idem pour info
ainsi les tech RH ne voient que les tickets qui leur sont attribués, les tech infos ne voient pas les tickets RH
et le demandeur vois ses tickets RH et infos
pour attribuer automatiquement il y a plusieurs solutions : règle métier, en fonction de la catégorie, en fonction du collecteur....
personnellement, je le fais avec le plugin formcreator : un formulaire demande RH(attribue à RH), un formulaire info (attribue à info), etc..j'utilise le plugin formcreator , dans votre cas je creerait un formulaire "mes demandes RH", un formulaire "mes demandes informatique", etc... qui seraient
Offline
Bonjour,
J'ai mis en place dans une VM des formulaires pour chaque service comme indiqué dans votre message. Problème, quand un self-service d'un service/entité A rempli un formulaire à destination d'un serivce/entité B, ce dernier peut accéder au ticket crée par le formulaire qui lui est attribué, modifier ses informations, répondre au ticket, etc, mais le demandeur self-service du service A ne peut pas voir le ticket, seulement le formulaire. Quand je clique sur le formulaire qu'il a rempli, j'ai les onglets Réponse au formulaire, Tickets et Tous. Dans Réponse au formulaire je peut bien voir les informations que j'ai mis dans mon formulaire, mais quand je vais dans l'onglet Ticket, il y'a tout d'abord un petit "1" (ce qui montre bien qu'un ticket a été crée) et il est écrit "Pas de ticket trouvé".
Si je comprends bien, le demandeur self-service ne peux PAS accéder au ticket crée par son formulaire si le destinataire du formulaire n'appartient PAS à la même entité que le demandeur. C'est très embêtant.
Comment puis-je accéder à mon ticket et à son suivi? Est-ce qu'on ne peut vraiment pas communiquer entre entités sur GLPI?
Merci d'avance pour votre réponse, je reste bloquée.
LaDenrée wrote:la solution présentée par sico31 fonctionne mais elle oblige l'utilisateur demandeur à choisir son entité pour déposer le ticket dans la bonne entité ce n'est pas simple pour l'utilisateur (mais ça marche)
je préfère une gestion par groupe.
les techniciens qui gèrent les tickets avec un profil "voir les tickets attribué = oui, voir tous les tickets=non" et le reste identique à technicien
un groupe G_TechnicienRH qui contient les intervenants RH
un groupe G_TechnicienInfo qui contient les intervenants Infoles autres utilisateurs avec un profil self-service (voir mes tickets = oui)
ensuite vous faite attribuer automatiquement les demandes RH au groupe G_techniciensRH et idem pour info
ainsi les tech RH ne voient que les tickets qui leur sont attribués, les tech infos ne voient pas les tickets RH
et le demandeur vois ses tickets RH et infos
pour attribuer automatiquement il y a plusieurs solutions : règle métier, en fonction de la catégorie, en fonction du collecteur....
personnellement, je le fais avec le plugin formcreator : un formulaire demande RH(attribue à RH), un formulaire info (attribue à info), etc..j'utilise le plugin formcreator , dans votre cas je creerait un formulaire "mes demandes RH", un formulaire "mes demandes informatique", etc... qui seraient
J'ai l'impression que cette demande revient plus que regulierement mais jamais de methode reellement fonctionnel pour cela ce que j'ai du mal a comprendre vu le nombre de fois ou ceci est demandé sur le forum et sur internet en général car ceci est plus qu'un besoin ceci est une NÉCESSITÉ dans le monde de l'entreprise d'aujourd'hui avec les multiple interconnection des services (ENTITÉ dans GLPI) ....
Dommage qu'il n'y est pas de reponse (A par si .... ?)
Meme question encore et encore ...
https://forum.glpi-project.org/viewtopic.php?id=291087
ou encore
https://forum.glpi-project.org/viewtopic.php?id=291069
Et encore la ...
https://forum.glpi-project.org/viewtopic.php?id=290935
Last edited by lamy-v (2024-10-21 20:04:43)
Offline
.... mais jamais de méthode réellement fonctionnel...
FAUX !
il y a plein de cas où ça marche très bien;
posez vous la question : pourquoi voulez vous mettre les techniciens dans des entités différentes ?
plutôt que de faire naviguer le demandeur d'une entité à une autre pourquoi ne pas créer les tickets dans l'entité du demandeur ? et ce sont les techniciens qui naviguent dans les entités pour récupérer les tickets qui le concernent
avez vous imaginé une structure où tous les techniciens sont dans la racine avec un profil récursif, les sous entités représentent vos "services clients" qui contiennent vos utilisateurs demandeurs.
chaque demandeur crée des tickets dans son entité qui sont affectés à des groupes les techniciens (dans la racine avec un profil technicien récursif)) voient leurs tickets dans toutes les sous entités sans voir ceux des autres.
Trouver la panne avant de réparer...
GLPI10.0.16 (ubuntu 22.04 PHP8.1 Mariadb10.6 ) plugins : comportements 2.7.3 reports 1.16.0 formcreator 2.13.9, datainjection 2.13.5 fields 1.21.9
Offline
lamy-v wrote:.... mais jamais de méthode réellement fonctionnel...
FAUX !
il y a plein de cas où ça marche très bien;
posez vous la question : pourquoi voulez vous mettre les techniciens dans des entités différentes ?plutôt que de faire naviguer le demandeur d'une entité à une autre pourquoi ne pas créer les tickets dans l'entité du demandeur ? et ce sont les techniciens qui naviguent dans les entités pour récupérer les tickets qui le concernent
avez vous imaginé une structure où tous les techniciens sont dans la racine avec un profil récursif, les sous entités représentent vos "services clients" qui contiennent vos utilisateurs demandeurs.
chaque demandeur crée des tickets dans son entité qui sont affectés à des groupes les techniciens (dans la racine avec un profil technicien récursif)) voient leurs tickets dans toutes les sous entités sans voir ceux des autres.
Alors cette methodes fonctionne bien et pour la vision coté tech et c'est meme la bonne methode je dirais mais des que vous souhaiter gardez ce principe mais que vous souhaitez permettre a vos utilisateurs de "communiquer entre eux" (desoler je n'ai pas le bon terme surement) cela ne fonctionne plus car les sous entité bloque chaque utilisateur dans son entité donc utilisateur entité A ne pourras pas ajouter un utilisateur de l'entité B en observateur par exemple ...
Mais oui je suis d'accord vos reponses reponds a la problematique de base mais cela va surement engendrer d'autre blocage comme les liens indiqué et le message de @jiu2jiu
Offline
Pour moi il manque une fonction de liaison du self service entre entité souhaité (pour garder cette isolation) ou une liaison total mais qui fait un peu perdre le concept des entité
Offline