Hallo Mirco,

wir nutzen Otobo für mehrere Abteilungen auf einem Server.

Die Abteilungen haben dann eigene Emailadressen, die per Postmaster dann abgeholt werden und in die entsprechenden Queues geschoben werden.

Die Agenten (User) sind dann Mitglied der entsprechenden Gruppe, die auf die Queue gesetzt wurde.

Hier muss dann dann aufpassen, falls in einer Email beide Abteilungen drin sind. Hier kann es passieren, dass die Email nur  in der Queue von Abteilung 1 landet oder von Abteilung 2. Da müsste man die Filter dann testen.

Und Abteilungsübergreifend, verschiebt der Agent dann am Besten die Email in die jeweilige Queue, wenn die von einer anderen Abteilung bearbeitet werden soll.

Hoffe das ist halbwegs verständlich geschrieben :)

Gruß Marcel

Hallo Mirco,

wir haben für die Agenten, die das benötigen, in der entsprechenden Gruppe das Recht „verschieben in“ eingerichtet.

Wenn du eine Gruppe erstellt hast und dann unter „Agenten<->Gruppen“ den Agenten oder die Gruppe auswählst, kannst du die Rechte setzen.

Gruß Marcel

Hallo zusammen,

wir nutzen eine OTOBO-Instanz für den IT-Support, Teile der Verwaltung, das Liegenschaftsmanagement mit seinem Schließsystem und Hausmeistern, unsere Bibliothek, sowie für den 2nd-Level-Support für zentrale IT-Dienste.

Für mich ist das Schwierigste, die Konfiguration der Statuus, Ticket-Typen, SLAs und Co. so aufzubauen, dass die einzelnen Bereiche sich nicht in die Quere kommen: Solange alle einen Default-Ticket-Typ haben, ist alles kein Thema. Wenn aber die IT nach ITIL arbeiten möchte, kommt damit das Liegenschafsmanagement nicht immer so recht klar. Also baut man ACLs, die die Konfigurationen ein-/ausblenden. Das geht, macht aber die „schnelle“ Einführung von Neuerungen deutlich komplizierter und damit langsamer. Man muss bei allen Einstellungen aufpassen, dass man nicht die Arbeitsweisen einer anderen Einrichtung tangiert. Dennoch sind wir bei einer Instanz geblieben, weil alles andere dann wieder den Overhead zweier zu konfigurierender/zu pflegender Systeme mit sich brächte.

Die Übergabe von Tickets und die Pflege der Berechtigungen wiederum ist innerhalb des einen Systems bei uns überhaupt kein Problem: Da alle im selben System arbeiten, haben wir einen Identifier und eine relativ große Menge an Queues mit verschiedensten Berechtigungen und  kommen damit gut klar. Die Übergabe zwischen Abteilungen/Einrichtungen geschieht in der Regel über die Eingangs-/Dispatch-Queues der Einrichtungen (so kann z.B. der IT-Support nur aus seinem Posteingang in andere Einrichtungen dispatchen, damit IMMER eine letzte Sichtung durch das SPOC-Team erfolgt, bevor das Ticket das eigene Hoheitsgebiet „für immer“ verlässt). Auch sind nicht alle Agenten zum Verschieben nach Extern berechtigt. Das Ziel ist dann immer der Eingangskorb oder die Haupt-Queue der anderen Betriebseinheiten, damit nicht „aus der Tiefe in die Tiefe“ an Dispatching/Monitoring vorbei gearbeitet werden kann. Der GenericAgent setzt gegebenenfalls auf Basis dieser Haupt-Queue auch noch Einstellungen oder löscht z.B. einen IT-SLA.

Zu empfehlen ist aus meiner Sicht in jedem Fall die konsequente Anlage von Queues -> Gruppen <-> Rollen <- Agenten, und die Zuweisung von Berechtigungen ausschließlich über den „Umweg“ der Rollen abzubilden. Spätestens, wenn ACLs dazu kommen, macht das einiges leichter und verständlicher.

Viele Grüße
Martin

Hallo,

ich habe ähnliches Problem wobei wir den Ansatz nehmen, das für jede externe Firma eine eigene Queue angelegt wurde. Was ist der beste Weg um sicherzustellen, dass die jeweilige externe Firma nur die eigene Queue sieht und eine Masterqueue in welche das Ticket zurück gegeben werden kann?
Sollen wir hierfür eigene Gruppen verwenden oder Rollen. Müssen die jeweiligen Queues dann der jeweiligen Gruppe zugeordnet werden oder sollen diese in der default „users“ gruppe bleiben?

Welche Rolle Gruppe soll ich der MasterQueue geben oder soll diese in der default users Gruppe bleiben

Brauchen wir dann noch zusätzlich ACLs?

Die einzelnen Agents möchte ich möglichst nur bei der Anlage angreifen und maximal einer Rolle oder Gruppe zuordnen und nicht immer manuell die notwendigen Rechte per User setzen-

Vielen Dank

Thomas

Ich denke ich habe es nun selbst gelöst wie in einer oberen Antwort geschrieben mittels Queue –> Gruppen –> Rollen –> Agents.

Sprich jede Queue (CompanyA) wurde auf eine Gruppe (Gruppe-CompanyA) gesetzt. (MasterQueue –> Gruppe-Master)

Es wurde jeweils eine Rolle erstellt (Rolle-CompanyA), und über „Roles<->Groups“ wurde der Rolle voller Zugriff auf die jeweilige Gruppe erteilt (Gruppe-CompanyA) und nur „move to“ Rechte auf die „Gruppe-Master“.

Die Agents wurden dann der jeweiligen Rolle zugeordnet via „Agents<->Roles“

Alle Agents wurden aus der default „user“ Gruppe entfernt und es werden weitere Agents nur noch Rollen zugeordnet.

Ich denke das ist der korrekte Weg.

ACLS etc. sind hierfür nicht notwendig.