OTOBO: Prozesse im Kundeninterface starten
In der ((OTRS)) Community Edition und in Znuny können im Prozesse im Kundeninterface über Aktivitätsdialoge gestartet werden, die im Prozessmanagement auch für den Kundenbereich freigegeben sind. Sobald das der Fall ist, bekommt der Kundenbenutzer einen neuen Menüeintrag zu sehen, über den ein Dialog erreichbar ist. In diesem Dialog wird dann der Prozess ausgewählt, der gestartet werden soll.
In OTOBO ist das anders. Die Kundenbenutzer sollen im Kundenbereich nur einen einzigen Einstiegspunkt haben, über den Tickets erstellt werden können (Tickets per Mail oder über eine Schnittstelle bleiben unberührt).
Für Administratoren ist das eine Umstellung, da die Aktivitätsdialoge für den Prozesseinstieg über andere Mechanismen dargestellt werden müssen. In OTOBO können Access Control Lists (ACLs) nicht nur Werte in Dropdowns einschränken (siehe https://doc.otobo.de/manual/admin/10.1/en/content/processes-automation/access-control-lists.html, sondern auch Formularfelder ausblenden.
Nehmen wir an, dass Kundenbenutzer über das Portal verschiedene Zugänge (z.B. Mailaccount, Gitlab-Account, ...) beantragen können. Weiterhin können in einem Prozess Demosysteme angefordert und anschließend Erweiterungen bestellt werden können:
Nachdem ein Demosystem beantragt wurde, muss es erstellt werden, der Kundenbenutzer muss die URL zugeschickt bekommen und nach einer gewissen Zeit muss der Kundenbenutzer an das Demosystem erinnert werden.
Der Kundenbenutzer soll im Kundenbereich den Zeitraum der Demo verlängern können und/oder die Erweiterung(en) bestellen können. Die entsprechenden Aktivitätsdialoge sind dann bei der Aktivität Entscheidung angesiedelt:
Je nachdem welcher Prozess gestartet wird, sollen unterschiedliche Felder zu sehen sein. Für den Demosystem-Prozess muss der Kundenbenutzer erstmal auswählen, dass ein Demosystem gewünscht ist (das wird über Tickettypen gesteuert):
Wird Demosystem anfordern ausgewählt, sollen folgende (Dynamischen) Felder eingeblendet werden:
- System (Znuny oder OTOBO)
- Znuny-Erweiterung oder OTOBO-Erweiterung (je nachdem, was als System ausgewählt wurde)
Die Dynamischen Felder für die Prozesse müssen für die Ansicht CustomerTicketMessage eingeblendet werden:
Damit sieht der Dialog für neue Tickets im Kundenbereich so aus:
Da die Felder aber nur für die Prozesse benötigt werden, müssen sie erstmal wieder ausgeblendet werden. Das stellen wir über ACLs dar:
Auf den Dialognamen kommt man, wenn man in die URL schaut, unter der Kundenbenutzer Tickets erstellen können:
Je nach ausgewähltem Tickettypen wird das System-Feld und das Dropdown mit den Erweiterungen eingeblendet:
Sollte FormStd bei den ACLs nicht zur Verfügung stehen, kann das über die Systemkonfiguration hinzugefügt werden
Eine Hilfe, was in den ACLs bei Form etc. eingetragen werden kann, ist unter https://doc.otobo.org/manual/admin/10.1/en/content/processes-automation/access-control-lists.html?#acl-reference zu finden.
Hat der Kundenbenutzer alles ausgewählt und das Ticket wird erstellt, muss es dem Prozess zugeordnet werden. Das wird über einen GenericAgent erledigt. Immer dann wenn ein Ticket erstellt wird und der Tickettyp Demosystem-Anforderung ist, muss das Dynamische Feld ProcessManagementProcessID auf die Prozess-ID und das Feld ProcessManagementActivityID auf die Aktivitäts-ID gesetzt werden.
(Für den Screenshot wurden für die Übersichtlichkeit einige Felder entfernt).
Die konkreten Prozess- und Aktivitäten-IDs müssen Sie im Prozessmanagement auslesen.
Der Agent soll jetzt einen Dialog bekommen, um die URL etc. eintragen zu können. Und der Kundenbenutzer soll die Demo verlängern und/oder die Erweiterung(en) bestellen können. Das sind dann wieder Aktivitätsdialoge wie man sie aus dem Standard-Prozessmanagement kennt.
Diese Dialoge sind dann im Kundenbereich über die Ticketansicht erreichbar:
Wenn Sie diesen Prozess einmal selbst nachstellen wollen, können Sie die notwendigen Dateien unter https://os.perl-services.de/perl-academy/otobo-kundenbenutzer-prozess herunterladen. Nur den GenericAgent und den Tickettypen müssen Sie händisch übernehmen.
Sollten Sie Bedarf an einer Admin-Schulung haben, nehmen Sie einfach Kontakt mit uns auf.
Permalink: /2021-12-29-otobo-prozesse-im-kundeninterface-starten
QuickClose und Ticket-ACLs
QuickClose startete als kleines Addon, mit dem man ohne viele Klicks ein Ticket schließen kann. Sowohl in der Ticketansicht als auch in den Ticketübersichten (z.B. Ansicht nach Status
) wird ein Dropdown mit den QuickClose
-Aktionen angezeigt.
Nach und nach wuchs die Erweiterung, so dass man die Tickets auch verschieben kann, nicht nur geschlossen
-Status auswählen kann und vieles mehr.
Ab sofort ist es möglich, die Aktionen auch über Ticket-ACLs einzuschränken. Gegeben sind folgende QuickClose-Aktionen:
Ziel ist es, die bei Tickets aus der Queue Raw
die ersten beiden Aktionen zu verbieten.
Dazu nehmen erstellen wir eine neue ACL:
Die Filterbedingungen sind ganz normaler Standard. In diesem Fall sind alle Tickets in der Queue Raw
von dieser ACL betroffen.
Entscheidend ist, was bei der Wertänderung steht. Um QuickClose-Aktionen auszuschließen, müssen wir PossibleNot wählen. Damit wird bestimmt, was an einem Ticket nicht gemacht werden darf.
Wir nutzen hier dann Action. Normalerweise wird dieser Parameter genutzt um Frontendmodule auszuschließen. Sollen z.B. Tickets nicht geschlossen werden dürfen, würde man hier AgentTicketClose eintragen. Aber die TicketACLs auszuweiten ist nicht ohne größere Codeänderungen möglich. Aus diesem Grund nutzen wir Pseudo-Actions. Die setzen sich aus AgentTicketQuickClose_
und dem Namen der QuickClose-Aktion zusammen.
Für ein Ticket aus der Queue Raw
sieht das QuickClose-Dropdown so aus:
In den Ticketübersichten werden noch alle QuickClose-Aktionen angezeigt. Wird eine Aktion auf ein Ticket angewendet, was durch eine ACL verboten ist, dann wird eine entsprechende Fehlermeldung angezeigt.
Existieren viele QuickClose-Aktionen und es sollen alle Aktionen ausgeschlossen werden, kann ein Regulärer Ausdruck genutzt werden:
Permalink: /2021-01-22-quick-close-und-ticket-acl
TicketChecklist: Schließen des Tickets verhindern
Eine häufiger gestellte Frage ist, wie man verhindern kann dass ein Agent ein Ticket schließt solange noch mindestens eine Aufgabe aus der Checkliste noch offen ist. Hier kann man sich die Ticket-ACLs zu Nutze machen. Immer wenn eine Aufgabe zur Checkliste hinzugefügt wird oder der Status einer bestehenden Aufgabe geändert wird, wird geprüft ob alle Punkte schon abgearbeitet sind oder nicht. Ist das nicht der Fall, wird das Dynamische Feld TicketHasOpenTodos auf den Wert 1 gesetzt.
Auf diesen Wert kann man in der ACL prüfen. Die Prüfung lautet: ist der Wert des Dynamischen TicketHasOpenTodos gleich 1, dann darf das Ticket nicht geschlossen werden. In der ACL sieht das dann wie folgt aus:
Bei den Wertänderungen muss man ausschließen, dass der Agent den Schließen
-Dialog aufruft und die geschlossen
-Status sollen in allen anderen Dialogen ausgeschlossen werden:
Wie erkennt TicketChecklist bei eigenen Aufgaben-Status, ob die Aufgaben geschlossen sind oder nicht? Dazu gibt es eine SysConfig-Option die gepflegt werden muss:
Wenn keine Aufgabe einen dieser Status hat, sind alle Aufgaben geschlossen.
Nach dem Speichern der ACL das Deployen
nicht vergessen. Sonst ist die ACL nicht aktiv. Und nicht mit dem Superuser (root@localhost) testen, denn da greifen keine ACLs.
Haben wir Ihr Interesse an TicketChecklist geweckt? Dann nehmen Sie doch einfach Kontakt zu uns auf oder fordern Sie gleich Ihr Demosystem an.
Haben Sie noch weitere Ideen und Wünsche? Dann schreiben Sie uns bitte.
Permalink: /2017-04-20-ticketchecklist-schliessen-verhindern