-
Beiträge
-
-
Hallo zusammen!
Mein Unternehmen hat sich entschieden, von Jira auszutreten. Wir sind auf der Suche nach einer Alternative und sind dabei auf OTOBO gestoßen. Ich habe mal eine OTOBO 10.1.6 Testumgebung aufgesetzt und ich bin persönlich damit zufrieden, aber es gibt noch einige offene Punkte die wir klären müssen.
1. Workflows
In Jira konnten wir Workflows einrichten, die definieren, wie ein Ticket verlaufen kann, z.B. muss ein offenes Ticket erst auf „in Bearbeitung“ gesetzt werden, damit es geschlossen werden kann. Ich denke mir, sowas wäre mit etwas Aufwand mit den ACLs umsetzbar, bin mir aber nicht so sicher.
2. Zugriff auf Kunden(benutzer)verwaltung
Wir möchten die Verwaltung der Kundenbenutzer den Admins überlassen, wissen aber nicht, wie wir den Zugriff darauf beschränken.
3. Vereinfachung der Agentenoberfläche
Die Kundenoberfläche ist sehr ansprechend, besser sogar als Jira. Dagegen die Agentenoberfläche… gewöhnungsbedürftig. Im welchen Umfang kann man die Agentenoberfläche vereinfachen, damit es annähernd so einfach zu bedienen ist wie Jira? Wir verwirren uns vor allem in der Ticketansicht bei Begriffen wie „Telefon-Ticket“ und „Besitzer“ und „Verantwortlicher“.
4. Teilen der Tickets unter mehreren Kundenbenutzern
In Jira können mehrere Agenten und Kunden ein Ticket abonnieren und Benachrichtigungen erhalten. Nach meinem Wissensstand können Kunden im selben Unternehmen untereinander Tickets sichten, aber es wird z.B. nur der Ersteller des Tickets benachrichtigt, nicht andere Beobachter.
5. Migration von Jira-Tickets nach OTOBO
Ist es möglich, Tickets von Jira (automatisch) nach OTOBO zu importieren?
6. Avatare
Dass Avatare nur über Gravatar gesetzt werden können, finden wir unglücklich. Gibt es da einen Umweg?
Falls mich jemand zu diesen Punkten aufklären kann, wird es uns deutlich leichter fallen, eine Entscheidung zu treffen. Danke im Voraus!
-Meik
-
Zu 2. sofern das Voll Admins sind, die auch das Gesamte System konfigurieren dürfen, sollten diese ja in der Gruppe „admin“ sein. Die Agenten Zuordnung macht man ja dann über den Punkt „Agenten <-> Gruppen“
Zu 6. da gab es mal ein Addon von maxence.de , das ist aber scheinbar für Otobo nicht auf dem aktuellen Stand.
https://www.maxence.de/otrs-community-edition/znuny-otobo-add-ons/localavatar/
Wir haben die Avatare aber über den Punkt „Frontend::AvatarEngine“ in der Systemkonfiguration abgeschalten.
Gruß Marcel
-
Hallo Marcel,
danke für die Antwort. Zu 2: Das Problem ist eigentlich dass normale Agenten (in der Gruppe „users“) die Kundenbenutzer verwalten können (erstellen, bearbeiten, gültig oder ungültig setzen etc.) und das möchten wir verhindern.
Zu 6: Beim Versuch das Paket zu installieren bekomme ich die Meldung: „Dieses Paket kann nur mit OTOBO-Version 6.0.x oder neuer verwendet werden“ Eigentlich habe ich ja 10.1.6 was das Kriterium erfüllt aber es scheint trotzdem nicht kompatibel zu sein.
-Meik
-
-
Hallo Meik,
- genau, das kann auf verschiedene Arten und weisen gehen – bspw. mit ACLs, ggf. kann hier auch das Prozessmanagement unterstützen.
Kleiner persönlicher Hinweis: ein Status „in Bearbeitung“ kann weggelassen werden, weil durch die Kombination von Status (bspw. „offen“) und der Ticketsperre schon ersichtlich sein sollte, ob das Ticket bearbeitet wird. Aber das nur aus Beratungssicht am Rande. - Die Agenten-Zuordnung bitte über „Agenten <-> Rollen“ und „Rollen <-> Gruppen“ lösen, statt über „Agenten <-> Gruppen“ => den Button blende ich gerne aus.
Zum eigentlichen Problem: die Gruppe „users“ steuert standardmäßig die Aktionen. Du kannst entweder- den normalen Agenten diese Gruppen-Berechtigungen wegnehmen oder
- eine andere (neue) Gruppe hinter diese Aktionen packen
- Vereinfachen lässt sich vieles. Bspw. ist der Verantwortliche standardmäßig überhaupt nicht aktiviert, das kann man einfach wieder deaktivieren. Schau gerne mal in die Systemkonfiguration unter Core > Ticket, da findest du einige Einstellungen zu grundlegenden Funktionen, die man deaktivieren kann.
Sollte es dir um die Benamung gehen, so kann man das bspw. über die Übersetzungen regeln und für das englische Original „Owner“ bspw. als deutsche Übersetzung „aktueller Bearbeiter“ o.ä. eintragen.
Außerdem kannst du in der Systemkonfiguration viele Aktionen oder Knöpfe einfach deaktivieren (bspw. unter Frontend > Agent > Toolbar oder wenn du nach den „ModuleRegistration“-Optionen schaust). Hier lässt sich sehr vieles anpassen. - Das ist alles Einstellungssache. Um ein Team abzubilden, werden bspw. die Queues verwendet. Um bspw. Benachrichtigungen zu steuern, gibt es in den persönlichen Einstellungen die Möglichkeit (bspw.) Queues zu abonnieren. Außerdem findest du in den Einstellungen für die Ticket-Benachrichtigungen für jede einzelne die Möglichkeit, den/die Empfänger auszuwählen.
Zusätzlich könnte hier ggf. noch die Beobachten-Funktion (Ticket::Watcher) interessant sein. - Es gibt einen Standard-Konnektor in den Webservices. Der ist für eine dauerhafte Anbindung konzipiert, aber vielleicht findest du da ein bisschen Inspiration, wie du Daten (auch einmalig) austauschen kannst.
- Unter Frontend::AvatarEngine kannst du Gravatar deaktivieren, dann sieht man grafisch dargestellt die Initialen der Benutzer. Ansonsten müsste man hier eine Lösung noch entwickeln lassen. Da OTOBO open source ist, ist das ja grundsätzlich kein Problem.
Viel Spaß mit OTOBO!
Viele Grüße
Stefan - genau, das kann auf verschiedene Arten und weisen gehen – bspw. mit ACLs, ggf. kann hier auch das Prozessmanagement unterstützen.
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.