v28 Berechtigungskonzept und Ansicht eigener Tickets

[mplan]

Hallo,
wir sind dabei, das neue Berechtigunskonzept über die Base Permission und Ticket::Base Zuweisungen einzurichten. Bisher war es möglich bzw. über eine Rolle so konfiguriert, dass man seine eigenen Tickets ansehen konnte, auch wenn man nicht explizit Queue/Teamrechte hatte.

Code Auswählen Erweitern

Object /system/ticket/queues/*{Queue.QueueID GT 0} Queuezugriff über Query -----
Object /tickets/*{Ticket.OwnerID EQ $CurrentUser.UserID}                   CRUD-
Object /system/ticket/queues/*{Queue.QueueID IN [1,4]} Entry Queue         CR---
Object /tickets/*{Ticket.ResponsibleID EQ $CurrentUser.UserID}             CRUD-
Object /tickets/*{Ticket.ContactID EQ $CurrentUser.Contact.ID || Ticket.OrganisationID EQ $CurrentUser.Contact.PrimaryOrganisationID}
      Vollzugriff wenn User == Kontakt oder Organisation CRUD- Das ist jetzt nicht mehr möglich und man erhält eine Fehlermeldung beim Öffnen/Zugriff auf Tickets.
Wie kann erreichen, dass man mit den Base Permissions seine eigenen Tickets weiterhin einsehen/bearbeiten kann?
Die Rolle "Ticket Agent Base Permission" aoll nicht verändert werden, schon aus Sicht von zukünftigen Updates.
Deshalb wird eine darauf aufbauende Rolle genutzt. Meine Versuche, den Zugriff auf die eigenen Tickets zu ermöglichen, funktionieren nicht.

Viele Grüße
Michael

[Torsten Thau]

Hallo,

sofern mit "eigene Tickets" die Tickets gemeint sind, an denen der Ersteller als Kontakt gesetzt ist, muss das über das Kundenportal erfolgen. Ein Agent wird automatisch als Bearbeiter, Verantwortlicher entfernt wenn er keine ausreichenden Berechtigungen zur Bearbeitung eines Tickets hat.

Was aber perspektivisch helfen könnte ist eine vorgesehene Erweiterung des Berechtigungskonstrukts: diese erlaubt auf Kindtickets die gleichen Rechte wie auf ein Elternticket auch wenn in der Queue dazu eigentlich nichts getan werden darf. Damit wäre das Konstrukt der Unteraufträge abgebildet und es bedarf keiner Verdrehungen am Berechtigungssystem.

Wenn das Dein Szenario abbildet, bitte ich um kurzes Feedback - dann nehme ich das mal als weiteren betroffenen Anwender auf und das gewichtet höher.

CU, Torsten

[mplan]

Hallo Torsten,
bin mir nicht sicher, ob ich Deine Antwort richtig verstehe. Stehe wohl wieder etwas auf dem Schlauch...
Man kann es bei uns evtl. in zwei Fälle unterscheiden:

• normaler Ticket Agent bzw. MA mit Zugang zum Agentenportal.
  Der MA soll die Tickets, bei denen er Bearbeiter oder Verantwortlicher ist, bearbeiten dürfen, auch wenn er kein Team-Mitglied ist bzw. nur Lese-Rechte dafür besitzt. Beispiel wäre das Senden eines Tickets an ein anderes Team, bei dem ergänzende Angaben einzutragen sind oder das Ticket wieder zurückgeholt werden soll
• Kundenkontakte, mit Zugang zum Agent-Portal (SSP auch möglich - wir hatten schon mal über diese Konstellation gesprochen ... ;-) )
  Der Kunde hat eine eigene Queue, soll aber auch in der Lage sein, im Agent-Portal seine eigenen Tickets, bei denen er Kontakt oder Verantwortlicher oder Bearbeiter ist, zu suchen und zu bearbeiten. Der Kunde kann seine Tickets an ein bestimmtes Team weitergeben, soll dort aber grundsätzlich nur Lese-Rechte, maximal Update-Rechte haben. Außerdem soll er Tickets in der normalen Eingangsqueue erstellen dürfen.

Man kann sowohl Verantwortlicher als auch Bearbeiter eines Tickets sein.
Das Erstellen von Tickets in der Queue und Lese-Rechte kann man prima mit den Base Permissions abbilden. Die Erweiterung der Rechte für eigene Tickets ist hier aber beschränkt bzw nicht vorhanden, wenn ich das Deiner Antwort richtig entnehme.

Wie passt hier das genannte Eltern-und Kind-Ticket hinein? Die MA/Kunde sind bei uns ja immer Verantwortlicher und /oder Bearbeiter des Tickets.
Wie ist das Konstrukt der Unteraufträge zu verstehen - ein Art Split des Haupt(Eltern-)Tickets?

Vielen Dank schon mal und viele Grüße
Michael