Standard Rolle für Kunden -> Kundenfrontend, Queues

Hallo OTRS-Gemeinde, ich suche eine Möglichkeit analog zu CustomerGroupAlwaysGroups für Customer eine Rolle zuzuordnen. Hintergrund ist folgende Problematik: Queues (Auszug): ServiceDesk (Gruppe Servicedesk) - Aufträge - Störungen RZ-Betrieb (Gruppe RZ-Betrieb) - Aufträge - Störungen - Event-Management Entwicklung (Gruppe Entwicklung) - Aufträge - Störungen Maileingang (Gruppe Servicedesk) - Webtickets Datenschutz (Gruppe Datenschutz) Durch das Anlegen der Queues und der Zuordnung zu unterschiedlichen Gruppen kann ich definieren welcher Agent in welcher Queue welche Rechte hat. Dies ist notwendig, da bei uns alle Tickets über das ServiceDesk laufen und z.B. ausser dem Datenschutzbeauftragten keiner die Tickets in Datenschutz zu lesen hat. RZ-Betrieb darf also kein Ticket an die Entwicklung schreiben, das Ticket geht erst zurück an den SD. Dieser ist bei uns SPOC (Single Point of Contact). Wenn also die Störung vom RZ-Betrieb nicht behoben werden kann, sondern dies von der Entwicklung vorgenommen werden werden muß (was bekanntlich länger dauert), geht das Ticket zurück an SD, damit dieser den Kunden informieren kann. Erst dann geht das Ticket vom SD an die Entwicklung... und von denen zurück an den SD. Der SD kann jetzt den Kunden informieren und das Ticket schließen. (Vielleicht ist da ja schon ein Denkfehler drin, aber dazu später mehr...) Wir ziehen unsere Kunden (2500 Stück) per LDAP aus dem AD (ActiveDirectory) sie werden (bisher) NICHT in der OTRS-DB abgelegt oder gesynct. Der Kunde nutzt jetzt das Kundenfrontend... dort sieht er jedoch von seinen Tickets nur die, welche in Queues sind, auf die der Kunde zugriff hat. Also eine Gruppe "Kunde" angelegt, eine Queue "WebTickets" angelegt und dieser Queue die Gruppe "Kunde" zugeordnet. Den Kunden mittels $Self->{'CustomerGroupAlwaysGroups'} = ['Kunde']; eine "default"-Gruppe zugeordnet. Wunderbar, er kann jetzt Tickets in der Queue "Webtickets" anlegen. Sobald jedoch das Ticket in eine andere Queue verschoben wird, ist das Ticket über das Kundenfrontend nicht mehr vorhanden. Das ist ziemlich blöd! Also habe ich mir gestern Gedanken gemacht, wie man das ganze elegant lösen kann. Dazu gibt es zwei Wege, wovon ich den ersten favorisiere: 1. Rollen Ich lege eine Rolle Kunden an, dieser erlaube ich den lesenden Zugriff auf alle Gruppen (ro) Aufgrund der LDAP-Nutzung sind die Kunden nicht unter "Benutzer" aufgelistet, daher kann ich diesen keine Rollen zuweisen, was auch einen erhebliche Mehraufwand bedeuten würde, da wir täglich Nutzer hinzubekommen und diese dann jeweils im OTRS konfiguriert werden müßten. Unter Benutzer sind nur die Agents vorhanden. Unter "Rollen <> Gruppen" kann ich definieren, das die Rolle "Kunde" in allen Gruppen lesen kann und in der Gruppe "Kunde" auch schreiben darf. Somit müßte es nun möglich sein, daß der Kunde seine Tickets sieht, die in Queues liegen, auf die die Gruppe "Kunde" eigentlich keinen Zugriff hat. (soweit klar?) Jetzt kommt der Haken an der Sache: Wie kann ich den Kunden eine Standard-Rolle zuweisen? Gibt es sowas wie {'CustomerGroupAlwaysRolls'} analog zu {'CustomerGroupAlwaysGroups'} ??? 2. Teilen des Tickets Alternativ kann natürlich das Ticket des Kunden in der Queue "Webtickets" verbleiben. Das Ticket wird geteilt und dann (das neue Ticket) an den RZ-Betrieb abgegeben. Nachteil 1: Beim Teilen eines Tickets wird dieses nicht automatisch mit dem Ursprungsticket verknüpft. Nachteil 2: es sind für einen Vorgang mehrere Tickets zu pflegen und Last but not least Nachteil 3: Dem Kunden wird selbst wenn es ein verknüpftes Ticket gibt, das in einer anderen Queue von einer anderen Gruppe bearbeitet wird, dies im Kundenfrontend nicht angezeigt.... ---------------------------------------------------------------------------------------------------------------------------- Mit freundlichen Grüßen Markus Schröder IT-Service-Management Datenschutzbeauftragter FinanzDock AG Kaistraße 2 40221 Düsseldorf Telefon: +49 (211) 95717 - 410 Telefax: +49 (211) 95717 - 411 m.schroeder@finanzdock.com www.finanzdock.com FinanzDock AG, Sitz: Düsseldorf; Registergericht: Amtsgericht Düsseldorf HRB 53535 Vorstand: Gerd Janssen, Wolfgang Schneider Vorsitzender des Aufsichtsrates: Moritz Schildt Prokura: Marlies Fedozejew, Matthias Kroth Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen außer für den Fall von Vorsatz oder grober Fahrlässigkeit die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mails aus. Jede von uns versendete E-Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus, so daß Ansprüche gegen die FinanzDock AG - gleich welcher Art - hieraus nicht abgeleitet werden können.

Schröder schrieb:
Hallo OTRS-Gemeinde,
ich suche eine Möglichkeit analog zu CustomerGroupAlwaysGroups für Customer eine Rolle zuzuordnen. Hintergrund ist folgende Problematik: Queues (Auszug):
ServiceDesk (Gruppe Servicedesk) - Aufträge - Störungen RZ-Betrieb (Gruppe RZ-Betrieb) - Aufträge - Störungen - Event-Management Entwicklung (Gruppe Entwicklung) - Aufträge - Störungen Maileingang (Gruppe Servicedesk) - Webtickets Datenschutz (Gruppe Datenschutz)
Durch das Anlegen der Queues und der Zuordnung zu unterschiedlichen Gruppen kann ich definieren welcher Agent in welcher Queue welche Rechte hat. Dies ist notwendig, da bei uns alle Tickets über das ServiceDesk laufen und z.B. ausser dem Datenschutzbeauftragten keiner die Tickets in Datenschutz zu lesen hat. RZ-Betrieb darf also kein Ticket an die Entwicklung schreiben, das Ticket geht erst zurück an den SD. Dieser ist bei uns SPOC (Single Point of Contact). Wenn also die Störung vom RZ-Betrieb nicht behoben werden kann, sondern dies von der Entwicklung vorgenommen werden werden muß (was bekanntlich länger dauert), geht das Ticket zurück an SD, damit dieser den Kunden informieren kann. Erst dann geht das Ticket vom SD an die Entwicklung... und von denen zurück an den SD. Der SD kann jetzt den Kunden informieren und das Ticket schließen.
(Vielleicht ist da ja schon ein Denkfehler drin, aber dazu später mehr...)
Wir ziehen unsere Kunden (2500 Stück) per LDAP aus dem AD (ActiveDirectory) sie werden (bisher) NICHT in der OTRS-DB abgelegt oder gesynct.
Der Kunde nutzt jetzt das Kundenfrontend... dort sieht er jedoch von seinen Tickets nur die, welche in Queues sind, auf die der Kunde zugriff hat. Also eine Gruppe "Kunde" angelegt, eine Queue "WebTickets" angelegt und dieser Queue die Gruppe "Kunde" zugeordnet. Den Kunden mittels $Self->{'CustomerGroupAlwaysGroups'} = ['Kunde']; eine "default"-Gruppe zugeordnet. Wunderbar, er kann jetzt Tickets in der Queue "Webtickets" anlegen.
Sobald jedoch das Ticket in eine andere Queue verschoben wird, ist das Ticket über das Kundenfrontend nicht mehr vorhanden. Das ist ziemlich blöd! Also habe ich mir gestern Gedanken gemacht, wie man das ganze elegant lösen kann. Dazu gibt es zwei Wege, wovon ich den ersten favorisiere:
1. Rollen Ich lege eine Rolle Kunden an, dieser erlaube ich den lesenden Zugriff auf alle Gruppen (ro) Aufgrund der LDAP-Nutzung sind die Kunden nicht unter "Benutzer" aufgelistet, daher kann ich diesen keine Rollen zuweisen, was auch einen erhebliche Mehraufwand bedeuten würde, da wir täglich Nutzer hinzubekommen und diese dann jeweils im OTRS konfiguriert werden müßten. Unter Benutzer sind nur die Agents vorhanden.
Unter "Rollen <> Gruppen" kann ich definieren, das die Rolle "Kunde" in allen Gruppen lesen kann und in der Gruppe "Kunde" auch schreiben darf. Somit müßte es nun möglich sein, daß der Kunde seine Tickets sieht, die in Queues liegen, auf die die Gruppe "Kunde" eigentlich keinen Zugriff hat. (soweit klar?)
Jetzt kommt der Haken an der Sache: Wie kann ich den Kunden eine Standard-Rolle zuweisen? Gibt es sowas wie {'CustomerGroupAlwaysRolls'} analog zu {'CustomerGroupAlwaysGroups'} ???
2. Teilen des Tickets Alternativ kann natürlich das Ticket des Kunden in der Queue "Webtickets" verbleiben. Das Ticket wird geteilt und dann (das neue Ticket) an den RZ-Betrieb abgegeben. Nachteil 1: Beim Teilen eines Tickets wird dieses nicht automatisch mit dem Ursprungsticket verknüpft. Nachteil 2: es sind für einen Vorgang mehrere Tickets zu pflegen und Last but not least Nachteil 3: Dem Kunden wird selbst wenn es ein verknüpftes Ticket gibt, das in einer anderen Queue von einer anderen Gruppe bearbeitet wird, dies im Kundenfrontend nicht angezeigt....
----------------------------------------------------------------------------------------------------------------------------
Mit freundlichen Grüßen Markus Schröder []
Hallo, da ist wirklich ein Denkfehler drin. Kunden können keine Rollen zugeordnet werden. Das passiert in der OTRS-DB, und dort stehen in der Regel auch keine Kunden drin. Diese sind weit besser in LDAP aufgehoben. Lösung: CustomerGroupSupport NICHT setzen (=0) Die Queues, in welche der Kunden Tickets ablegen darf unter CustomerPanelOwnSelection eintragen. Jetzt sieht der Kunde alle seine Tickets, völlig unabhängig von Gruppen und Rollen. Ist bei uns so eingerichtet und funktioniert prächtig. Grüße, Stefan Schwarz
participants (2)
-
Schröder, Markus
-
Stefan Schwarz