Blog

11.03.2022 // Renée Bäcker

Wir erarbeiten das mit Hilfe von zwei Personen:

Frau Schneider ist Leiterin der Abteilung Einkauf und Herr Müller Leiter der Abteilung Verkauf. In beiden Abteilungen wird Znuny (oder ((OTRS)) Community Edition oder OTOBO ...) eingesetzt. Damit Änderungswünsche der Abteilungen schnell umgesetzt werden können, sollen beide Zugriff auf bestimmte Teile der Administration bekommen.

Beide sollen Vorlagen bearbeiten (und Queues zuweisen) dürfen, Frau Schneider darf noch Signaturen bearbeiten und Herr Müller darf Ticketstatus bearbeiten. In der Übersicht:

• Frau Schneider: Vorlagen verwalten, Vorlagen zu Queues zuordnen, Signaturen verwalten
• Herr Müller: Vorlagen verwalten, Vorlagen zu Queues zuordnen, Ticketstatus verwalten

Den Rest der Administration dürfen die beiden nicht sehen.

Wenn die beiden Personen sich im Ticketsystem einloggen, sehen sie gar nichts vom Adminbereich. Das heißt, es muss zuerst einmal dafür gesorgt werden, dass sie überhaupt das Tor zum Adminbereich sehen.

Da in den Ticketsystemen Berechtigungen über Gruppen bzw. Rollen vergeben werden und nicht direkt an Personen, werden zunächst zwei neue Gruppen benötigt:

• admin_verkauf
• admin_einkauf

Und dann dürfen alle Personen die zu diesen Gruppen gehören im Adminbereich tätig sein. Es gibt ja vielleicht auch Stellvertreter:innen für Frau Schneider und Herrn Müller.

Geben wir also Frau Schneider die Berechtigungen auf die Gruppe:

Für diese beiden Gruppen wird das Tor zum Adminbereich über die Systemkonfiguration sichtbar gemacht. Um zu wissen, was das Tor ist besuchen wir selbst den Adminbereich. Dann sieht man in der URL den Parameter Action:

Die beiden Gruppen brauchen auf diese Action die Berechtigung. Alle *Action*s im Ticketsystem werden von *Frontend::Module*n umgesetzt. In der Systemkonfiguration kann man nach genau dieser Einstellung suchen:

Da in diesem Fall viele Treffer gefunden werden, kann man einfach mit ENTER zu diesem Punkt springen.

Die Frontendmodule im Adminbereich sind in der Systemkonfiguration über die Navigation unter Frontend → Admin → ModuleRegistration zu finden.

In der Einstellung Frontend::Module###Admin müssen jetzt die beiden Gruppen admin_verkauf und admin_einkauf unter Group eingetragen werden.

Für alle Frontend::Module###-Einstellungen gilt, dass nur Mitglieder der Gruppen die unter Group eingetragen sind, diese Seiten auch benutzen dürfen.

Das heißt, dass in diesem Fall alle Mitglieder von admin, admin_verkauf und admin_einkauf den Adminbereich betreten dürfen. Das ist aber noch nicht alles.

Jetzt dürfen Frau Schneider und Herr Müller zwar den Adminbereich betreten, sehen in der Navigationsleiste aber immer noch nicht das Hinweisschild zum Adminbereich. Zu (fast) allen Frontendmodulen gibt es auch eine passende Einstellung in der Systemkonfiguration in Bezug auf die Navigation. Die heißen dann nicht Frontend::Module###, sondern Frontend::Navigation###. Auch hier müssen die beiden Gruppen unter Group eingetragen werden:

Das war aber immer noch nicht alles. Denn wenn jetzt jemand aus den beiden neuen Gruppen den Adminbereich betreten, sehen sie ....... nichts:

Wir müssen also dafür sorgen, dass die neuen Gruppen auf die entsprechenden Frontendmodule berechtigt werden. Auch hier kann man die Bereiche einfach selbst aufrufen und über den Action-Parameter den Namen des Frontendmoduls herausfinden. In dem hier gezeigten Fall wären das:

• admin_verkauf: AdminTemplate, AdminQueueTemplates, AdminState
• admin_einkauf: AdminTemplate, AdminQueueTemplates, AdminSignature

Damit die Kacheln für diese Module im Adminbereich auftauchen, müssen die Gruppen noch in den Frontend::NavigationModule###-Einstellungen eingetragen werden:

Zusammenfassend heißt das:

• Neue Gruppen für die Frontendmodule berechtigen
• Den Navigationspunkt Admin für die neue Gruppe aktivieren
• Die notwendigen Kacheln für die neue Gruppe aktivieren

Sind dort die jeweiligen Einstellungen angepasst, sieht der Adminbereich für Frau Schneider so aus:

Wir sind dabei ein Modul zu entwickeln, dass diese Verwaltung der Mini-Admins vereinfacht.

Permalink: /2022-03-11-mini-admins-a-teile-des-adminbereichs-fa14r-agenten-freigeben

11.01.2022 // Renée Bäcker

Unsere Erweiterung TicketChecklist kann auch im Prozessmanagement eingebunden werden. Wie das funktioniert zeigt dieser Beitrag. Als Beispiel soll ein Prozess gestartet werden wenn eine neue Mitarbeiterin eingestellt werden soll. In einer Checkliste am Ticket sollen einige Dinge vermerkt sein, die so erledigt werden müssen:

Ein einfacher Prozess – der für den Beitrag stark verkürzt ist – könnte so aussehen, dass zu Beginn einfach ein Name eingetragen werden soll. Und ist das der Fall, steht als nächste Aktivität einfach nur die Erfassung an, dass der Vertrag da (und unterschrieben) ist. Ist das der Fall, geht der Prozess zu einer Aktivität ohne Dialog etc. (Prozessende).

Wenn der Prozess gestartet wird, also beim Übergang Daten eingegeben, soll die Checklistenvorlage zum Ticket hinzugefügt werden. Dazu muss eine neue Übergangsaktion erstellt werden. Dort muss das Aktionsmodul AddChecklist ausgewählt werden. Bei den Parametern wird nur der Schlüssel TemplateID benötigt und als Wert die ID der Vorlage.

Die TemplateID bekommt man, wenn man bei der Verwaltung der Checklistenvorlagen die Vorlage bearbeitet und in der URL nach dem Parameter ID schaut.

Zu Beginn ist nur die Aufgabe sign contract offen, die restlichen Aufgaben stehen auf warten. Das soll geändert werden, sobald der Vertrag unterschrieben ist. Dass der Vertrag unterschrieben ist, wird in der Aktivität Erfassung Vertrag und dem dazugehörigen Aktivitätsdialog erfasst.

Wenn der Vertrag unterschrieben ist, geht das Ticket im Prozess auch ein Stück weiter (hier: zu Prozessende). Das heißt, dass es einen Übergang gibt, den wir auch nutzen können um die erste Aufgabe zu schließen und andere Aufgaben zu öffnen. Dazu nutzen wir wieder Übergangsaktionen:

Als Aktionsmodul wird ChangeChecklistItems ausgewählt. Bei den Parametern muss immer festgelegt werden, welche Aufgaben (Items) geändert werden sollen. Das passiert über den Schlüssel Item_#. Die Reihenfolge in der die Aufgaben nummeriert werden ist meistens egal (außer man nutzt die Bedingungen und Aktionen der Checklistenvorlagen).

Als Wert zu Item_# muss der Text der Aufgabe wie in der Vorlage genutzt eingetragen werden. Darüber werden die Aufgaben identifiziert.

Mit der gleichen Nummer können die Änderungen an der Aufgabe definiert werden. In diesem Beispiel nutzen wir nur den Schlüssel Status_#, um den Status zu ändern. Schlüssel mit gleichem Wert für # gehören zusammen, also Item_1 und Status_1 etc.

Neben Stauts_# können noch folgende Schlüssel verwendet werden:

• Responsible_# um den Aufgabenverantwortlichen zu ändern
• DueDate_# um das Fälligkeitsdatum zu ändern und
• Priority_# um die Priorität zu ändern.

Permalink: /2022-01-11-ticketchecklisten-im-prozessmanagement