Autor Thema: Berechtigungen für Verschieben und Beobachten von Tickets in Teams  (Gelesen 557 mal)

mplan

  • Newbie
  • Beiträge: 128
Hallo,
wir möchten erreichen, dass Ticket Agents - Sub-Teams Tickets ihres Bereiches und eines gemeinsamen Bereiches sehen und bearbeiten können.Die Konfiguration wurde anhand der Dokumentation vorgenommen und passt soweit, was die Sichtbarkeit der Qeues/Teams betrifft.Nun soll es jedoch auch möglich sein, Tickets in ein anderes Team zu verschieben,welches außerhalb der eigenen zugelassenen Teams liegt.
Beispiel: Team"Account" hat Zugriff auf eine allgemeine Default-Eingangs-Queue und die Queue/Team "Account". Es soll ein Ticket vom Account-Team in ein anderes Team, z.B. "Clients" verschoben werden.
Das "Client" Team wird aber nicht gelistet in der Liste verfügbarer Teams. Das Ticket kann dem anderen Team nicht zugewiesen werden.
Wie kann man erreichen, dass der Agent das Ticket einem anderen Team zuweisen kann und sich ggf noch als Beoabachter mit eintragen kann, auch wenn er nicht Mitglied des Ziel-Teams ist.
Das Account Team hat die im Handbuch beschriebene Basic Ticket Agent Rolle und die Account Rolle mit:Object        /tickets/*{Ticket.QueueID IN [15,20]}    CRUD   
Resource    /system/ticket/queues/20                         R
Resource    /system/ticket/queues/15                         R   
Resource    /system/ticket/queues/5                         C U
Auf Team/Queue 15 und 20 soll Vollzugriff bestehen und Queue 5 ur die Möglichkeit, Tickets hinzuschieben.Vergibt man Leserechte, kann der Agent alle Tickets in der Queue 5 sehen (nicht gewollt)Vergibt man C+U Rechte sieht er auch alles, Gibt man nur C Rechte, kann er die Queue nicht mehr sehen.
Wie erreicht man, dass der Agent das Ticket an ein beliebiges Team weitergeben kann?
Update: Ich denke, die Sichtbarkeit der Ticket in Teams habe ich hinbekommen.
Der Nutzer kann ein Ticket in ein anderes Team verschieben, es danach aber nicht mehr sehen. Das ist OK.Bleibt noch die Frage, wie man das Ticket so auf die Watchlist setzen kann, dass man es auch nach dem Re-Queue noch in der Watchlist sehen kann. Derzeit ist es so, dass das Ticket niocht mehr im Zugriff ist, sobald es auf einer Queue landet, auf die man keinen Zugriff hat.




Viele Grüße, Michael

Torsten Thau

  • Global Moderator
  • Beiträge: 265
Hallo Michael,

sorry dass ich erst jetzt antworte. Dein Ansatz war (wie du schon selbst schriebst) richtig.

Da es nicht Zweck ist, alle Tickets in allen Queues sehen zu dürfen hier zunächst das grundsätzliche "Voll-Edit" auf Ressource Tickets kombiniert mit dem "Verbot" auf konkrete Ticket-Objekte
Resource | /tickets | CRUD-
Object      | /tickets/*{Ticket.QueueID GT 0} | -----

Um davon ausgehend nun ein Ticket von einer Queue A in eine Queue B verschieben zu können, bedarf es:

(1) Wissen darum, dass es die Queue A gibt (damit man die im Ticketdashboard angezeigt bekommt und am Ticket den Queue-/Teamnamen sieht)
Resource | /system/ticket/queues/<IDfuerQueueA> | -R---

(2) Berechtigung das Ticket wie es ist zu bearbeiten
Object | /tickets/*{Ticket.QueueID IN [<IDfuerQueueA>, <ggf weitere>]} | -R---

(3) Wissen darum, dass es die Queue B gibt  (damit man die in Bearbeitung im Feld "Team" offeriert bekommt)
Resource | /system/ticket/queues/<IDfuerQueueB> | -R---


Den Berechtigungen oben ist es aktuell egal ob das Ticket in Beobachtung ist oder nicht. Leider kann darauf noch keine Ausnahmeberechtigung gegeben werden.


CU, Torsten


PS: Ab v21 gibt es zur Vereinfachung zwei neue Rollen. Eine davon ist im Grunde der "Basic Ticket Agent". Sie heißt jedoch "Ticket Agent (w/o teams)" und bekommt im Release v22 noch ein paar fehlende Grundberechtigungen zur Verwendung mit Ticketvorlagen und -aktionen hinzu, die noch fehlend. Die andere Rolle heißt "Ticket Agent (Servicedesk)" und erlaubt den zugriff auf Tickets in Queue/Team "Servicedesk" und "Servicedesk/Monitoring". Sie kann als Vorlage für Team-spezifische Rollen genutzt werden.

mplan

  • Newbie
  • Beiträge: 128
Hi Torsten,
vielen Dank für Deine Antwort.
Ich habe es so hinbekommen, wie Du beschrieben hast.Die Rolle "Ticket Agent(w/o teams)" habe ich mit dem aus dem Handbuch ersetzt bzw. eine neue Rolle erstellt.Die Team-Rollen habe ich tatsächlich anhand der beiden vordefinierten Rollen aufgebaut.
Dort passt es mit den Zugriffen. Der Zugriff auf die Templates muß noch getestet werden.
Eine Frage hätte ich noch -
Kann man bei der Queue-Ressource eine ähnliche Syntax wie beim Ticket-Object verwenden? Also
Resource | /system/ticket/queues/*{Ticket.QueueID IN [<QueueA,QueueB]}Die Syntax funktioniert leider nicht so, aber gibt es so eine Schreibweise, so dass man die einzelnen Queues in einem einizgen Resource Statement zusammenfassen kann?
Viele GrüßeMichael

Torsten Thau

  • Global Moderator
  • Beiträge: 265
Hallo Michael,

ja es ist möglich die verfügbaren Queue-/Team-Objekte in der Form
Object | /system/ticket/queues/*{Queue.QueueID IN [1,2]} | -R---

...anzugeben. Bite beachten, dass es nicht mehr um "Tickets" geht, sonderen Queues ("Teams") - daher auch "Queue.QueueID" statt "Ticket.QueueID".

Damit das aber funktioniert, muss allerdings die Rolle "Ticket Agent (w/o teams)" angepasst werden

Resource | /system/ticket/queues/* | -----

muss ergänzt bzw. geändert werden zu

Object | /system/ticket/queues/*{Queue.QueueID GT 0} | -----

...dann arbeitet es nach den gleichen Prinzipien wie auch der Ticketzugriff.

CU, Torsten

mplan

  • Newbie
  • Beiträge: 128
Hi Torsten,

vielen Dank für die Klarstellung!

Das Beispiel hilft mir, ein besseres Gefühl zum Verständnis zu bekommen.  :-D
(Der Queue Kontext war mir eigentlich/grundsätzlich bewußt. Aber ich wußte nicht damit umzugehen.)
Vielen Dank!

VG, Michael

Tags: