Owner per Postmaster-Filter setzen

[mwilhelmi]

Hallo Zusammen,

ich möchte gerne per PMF-Job den Besitzer und Verantwortlichen eines neuen Tickets setzen.
Die entsprechenden X-OTRS-Owner bzw. Responsilbe Felder habe ich, aber wenn ich da den Loginnamen der Agents eintrage, wird es trotzdem nicht gesetzt.
Ich vermute, ich muss die Syntax der Agentnamen ändern? Kann mir jemand sagen, wie ich den Namen eintragen muss?

[Johannes]

Hi,

das passt. Der UserLogin ist korrekt bzw. X-OTRS Owner nutzt den Login. Bist du sicher das der Filter greift?
Das sollte sich auch im Nachrichtenprotokoll finden lassen.

Im Nachrichtenprotkoll bzw genau zur Zeit sollte sich dort dann ein Eintrag finden lassen, wenn es nicht klappt.
Gruß


P.S.
Bei FollowUps auf bestehende Tickets muss X-OTRS-FollowUp... genutzt werden.

[mwilhelmi]

Das ist meine Filter-Konfig:

PM-Filter.png

Und das ist dann in der History:

Downloads.png

Die Benachrichtigungen kommen aus den Ticketbenachrichtigungen. Damit sieht es für mich aus, als wenn er Owner und Resp. nicht zieht.

[mwilhelmi]

Wie meinst Du das mit dem Followup? Ziehen nicht die Filter nach der Ticketnummer als erstes?

[Johannes]

Schau bitte mal im Artikel selbst, also dem für das neue Ticket.
Dort müsste es einen Punkt "Kommunikationslog" geben, nicht die Historie des Tickets.
Dort werden die Aktionen, die am Ticket ausgeführt werden, geloggt.
Dann siehst du ob dein Filter überhaupt greift. Das wäre der Anfang würde ich sagen.

Zum Thema FollowUp, das ist richtig. Aber wenn Znuny ein FollowUp erkennt, nutzt es nur Filter die X-OTRS-FollowUp im Namen tragen. Alle anderen werden ignoriert.

[hkais]

ich möchte gerne per PMF-Job den Besitzer und Verantwortlichen eines neuen Tickets setzen.
Die entsprechenden X-OTRS-Owner bzw. Responsilbe Felder habe ich, aber wenn ich da den Loginnamen der Agents eintrage, wird es trotzdem nicht gesetzt.
Ich vermute, ich muss die Syntax der Agentnamen ändern? Kann mir jemand sagen, wie ich den Namen eintragen muss?

Ich würde die Finger vom PostmasterFilter lassen für solche Anforderungen.
Viel besser ist es einen Generic Agent zu bauen, der genau deinen Kriterien entspricht, den kannst Du jederzeit neu ausführen und damit gut Debuggen.

Als Tigger Event "TicketCreate" wählen => vergleichbar zum PMF trigger bei Eingang der Mail
deine Suchkriterien angeben
Beim Update deine Infos dazu packen (kannst Du oft grafisch tun)
Kannst sogar einen Note angeben
Und Du kannst es mehrfach ausführen, nicht nur, wenn die Mail (einmalig) eintrifft.
Und kannst es Powerusern beibringen...

[jojo]

Nein, der Generic Agent ist dafür nicht besser geeignet. Könntest Du einfach mal aufhören Dein halbseidenes "Fachwissen" hier zu verbreiten?

Für das Handling eingehender E-Mails sind die Postmaster Filter definitiv besser geeignet. GA haben diverse Downsides und können ein System bei entsprechender Größe auch lahmlegen.

[hkais]

nun ja, ich verbreite Wissen welches auf (leidiger) Erfahrung basiert.
Insb. dann wenn ein PostmasterFilter in die Hose geht, gehen oft auch komplette Inhalte von E-Mails flöten, die dan mit viel händischem Aufwand repariert werden müssen.
Diesen Umstand benennt allerdings niemand bei den Postmasterfiltern

Das ist mir mit GAs noch nie passiert...
... da ich hier vorstrukturierte Daten vorliegen habe
... und der GA mehrfach ausgeführt werden kann

wir können gerne diesen Thread dazu ausdiskutieren:
viewtopic.php?p=175284#p175284

Ich bin lernwillig, ich versuche immer sachlich zu bleiben ... und ändere gerne meine Meinung aus Benefits die von Lösungen herrühren.
Und ich vermeide es Andere zu beleidigen... um daraus einen Vorteil auf nicht-sachlicher Ebene zu erreichen...

[Johannes]

nun ja, ich verbreite Wissen welches auf (leidiger) Erfahrung basiert.
Insb. dann wenn ein PostmasterFilter in die Hose geht, gehen oft auch komplette Inhalte von E-Mails flöten, die dan mit viel händischem Aufwand repariert werden müssen.
Diesen Umstand benennt allerdings niemand bei den Postmasterfiltern

Stimme jojo zu und wir können das gern hier besprechen. Der verlinkte Thread ist genau so passend wie dieser hier.
Du hattest bisher schlicht und einfach besser aufgepasst bei GA oder hattest Glück. Ver-click dich einmal bei der Queue Liste und führe deinen GA aus. Führt auch zu Chaos. Setze durch Zufall den "Lösch" Schalter.

Egal was man macht, man muss sich damit schon beschäftigen und vorher testen. Sonst ist alles "gefährlich". Wir bieten mit der Software so viele Optionen an, klar kann man sich damit in den Fuß schießen.
Du kannst auch Master-Slave Tickets nicht vorher verstehen und sendest dann an 2000 Leute ein Mail raus. Dafür bieten ja diverse Dienstleister Schulungen, Bücher und was weiß ich nicht an. Damit man den Umgang mit dem System lernt und solche Fehler ggf. beachtet.

Diese Pauschalen Aussagen von Dir zum Thema Postmaster Filter sind schlicht unnütz und helfen Marc bei der Lösung seines Themas leider absolut nicht.

Mit deinem GA Ansatz stößt Du spätestens dann an Grenzen wenn Du dynamische Werte nutzen willst. Dann musst Du zwangsweise ein Modul nehmen, da du keinen Werte bzw. mehrere Werte in einem Filter, nutzen kannst.

[hkais]

Das ist meine Filter-Konfig:



Die Benachrichtigungen kommen aus den Ticketbenachrichtigungen. Damit sieht es für mich aus, als wenn er Owner und Resp. nicht zieht.

Nehmen wir ein konkretes Beispiel heran.

1. Ändere mal den Queuenamen von ii:QM
=> GA funktioniert weiterhin, da hier eine ID genutzt wird und damit der Name der Queue irrelevant & Schall und Rauch ist
=> Postmaster filter "defekt", da der Queuename ein String ist der damit nicht mehr exisitiert
2. Im Falle eines GAs
=> kann ich das Verhalten auch auf alten Tickets kurz testen, d.h. ich kann mir anschauen was passieren würde, wenn ich den GA ausführe
=> ich kann den GA auf ein Ticket beschränken und den GA solange testen, bis ich weiß er tut, dann auf weitere Tickets ausdehnen
=> ich muss hierfür kein Admin sein, der weiß wie ich auf CMD oder via SMTP e-mails ans System schicken kann
=> jeder NON-IT'ler ist in der Lage einen GA zu pflegen, wenn man ihm erklärt was zu tun ist und was er TUNLICHST bleiben lassen MUSS
3. alle Werte die im Screenshot sind, kann man per Dropdown auswählen
=> super easy nachzuvollziehen und wie in 2.) geschrieben dann auch zu testen

Stimme jojo zu und wir können das gern hier besprechen. Der verlinkte Thread ist genau so passend wie dieser hier.
Du hattest bisher schlicht und einfach besser aufgepasst bei GA oder hattest Glück. Ver-click dich einmal bei der Queue Liste und führe deinen GA aus. Führt auch zu Chaos. Setze durch Zufall den "Lösch" Schalter.

NOACK, bei einem GA kann ich den Lauf simulieren und mir mal die Tickets anschauen die betroffen wären.
Wie geht das bitte mit einem PMF?
Wenn ich unsicher bin, kann ich einfach mal ein weiteres Suchkriterium hinzunehmen, prüfen ob Kritierum gegriffen wurde und weiß damit welches Ticket wirklich angefasst wird. Jetzt kann ich das Ding einfach mal loslaufen lassen und mir das Ticket in Ruhe anschauen...

Egal was man macht, man muss sich damit schon beschäftigen und vorher testen. Sonst ist alles "gefährlich". Wir bieten mit der Software so viele Optionen an, klar kann man sich damit in den Fuß schießen.

Full-ACK
nur eben mit dem Unterschied beim GA kann ich sehen welche Tickets betroffen wären und kann auch quasi-"simulieren".

Du kannst auch Master-Slave Tickets nicht vorher verstehen und sendest dann an 2000 Leute ein Mail raus. Dafür bieten ja diverse Dienstleister Schulungen, Bücher und was weiß ich nicht an. Damit man den Umgang mit dem System lernt und solche Fehler ggf. beachtet.

Full-ACK. Trotzdem auf welcher Ebene schult man?
IT Experte (SMTP, CMD usw.) oder schule ich auf der Ebene PowerUsers für Znuny-UI Bedienung.
Ersteres ist IMHO ein Ansatz wenn man einen IT'ler (PMF/RegEx Experte) hat, letzterer ist ein Ansatz der "distributed" über Organizationsgrenzen und Abteilungen hinweg funktioniert (Generic Agents).

Diese Pauschalen Aussagen von Dir zum Thema Postmaster Filter sind schlicht unnütz und helfen Marc bei der Lösung seines Themas leider absolut nicht.

ACK
werde meine Aussage ggü. PMF präzisieren.
Ich meine aber nach wie vor für Basic Tasks, d.h. die Standardfelder (siehe Screenshot) ist ein GA besser geeignet, da alleine durch den "Probelauf" Fehler vorher auch von IT Laien gefunden werden können.
Und in unserer westlichen Hemisphäre sind Fehler die auf potentielle Massenfehler gehen, immer schlecht da diese "teuer", oft manuell repariert werden müssen.
Auch wir setzen PMFs ein, aber extrem selektiv und nur wenn wir via GAs nicht weiter kommen

Mit deinem GA Ansatz stößt Du spätestens dann an Grenzen wenn Du dynamische Werte nutzen willst. Dann musst Du zwangsweise ein Modul nehmen, da du keinen Werte bzw. mehrere Werte in einem Filter, nutzen kannst.

partial ACK
von Hause aus kann man (ob Bug oder Feature noch unklar) dynamische Felder bis 6 Stück auch via Module definieren.
Ansonsten haben wir einen transitionActionInvoker module gebaut, der TransitionActions rufen kann, die wiederum "Actions" als Module ausführen kann.
Wir diskutieren noch ob wir den als OSS bereitstellen. Hier ist dann mehr drin via GAs


@mwilhelmi
hier noch die kurze Anleitung eines GAs für deine Anforderungen:

• Jobname
  marcsGA
• Event Triggers
  Ticket Create
• Select -> From
  "*@marcsdomain.com*"
• Select -> From
  "*@marcsdomain.com*"
• Select -> Create times
  hier wähle ich etwas kurzes, z.B. 2h, d.h. die Zeit die ich evtl. benötige um Test-Tickets zu prüfen und Tickets in der Menge zu begrenzen wenn manuell der GA gerufen wird
• Update/Add Ticket Attributes -> Update/Add Ticket Attributes
  ii:QM auswählen
• Update/Add Ticket Attributes -> Set new Service Level Agreement
  hier deinen SLA auswählen
• Update/Add Ticket Attributes -> Set new agent/new owner
  hier deinen Onwer
• Update/Add Ticket Attributes -> usw.
• unter Add Note noch als From "Generic Agent", Subject etwas griffiges und im Note reference auf den GA Namen sowie ein Link auf eine Umsetzungsbeschreibung

So geben wir das immer weiter und die Agents können sich nicht rausreden:
- ich wusste nicht was zu tun ist
- ich dachte ticket wäre nicht für mich
- habe nicht verstanden was gemeint ist
- und die Supervisors können jederzeit einsehen was automatisch hinzugefügt wurde, da im Note sauber hinterlegt

[Johannes]

Ich musste da jetzt erstmal ein wenig drauf rum denken. Und versuche hier jetzt mal so neutral wie möglich zu antworten um dir und den Mitlesenden zu erklären wo ich die Hauptunterschiede sehe und warum GA kein Ersatz sind.

Die Testbarkeit ist beim GA ungefähr genau so schlecht wie bei den PM Filtern. Du siehst ja in der Preview nur welche Tickets betroffen sind. Aber nicht was gemacht wird. Du musst ihn also zwangsweise ausführen um wirklich zu sehen was passiert.
Deine Argumentation ergibt auch nur wirklich Sinn wenn Du kein Test System hast. Eine Testmail zu schicken bzw. in das System zu pipen, oder einen GA manuell auszuführen ist IMHO ein identischer Aufwand.
Zugegeben, der Import Export von PM Filtern ist im Moment nicht, ohne Addon, möglich das wird sich aber in der Zukunft ändern. Das ist ein Punkt den die GAs leider auch haben, aber für ein Staging ist also etwas manuelle Arbeit notwendig.

Was deine GA Logik, zumindest soweit es mir klar ist, nicht kann sind folgende essentielle Punkte:
- Filter arbeiten vor Autorespondern/Notifications
Wenn Du Ticket Notifications basierend auf Ticket Attributen nutzen willst, kommst Du mit dem GA Job nicht weit. Analog verhält es sich mit Sortierungen in Queues. Wenn Du z.B. nach Sprache sortierst und entsprechende Autoresponder schicken willst, brauchst Du einen Filter. Das kann der GA (wegen der Reihenfolge der Ausführung)
- Filter können Mails ignorieren (X-OTRS-Ignore) für Spam Tags zum Beispiel praktisch, wenn man nicht Herr des eigenen Mail Servers ist
- Filter können einzelne Werte, z.B. aus Formularen extrahieren und übernehmen. Auch so schöne Sachen wie Reply-To, CustomerID, CustomerNo usw.

GA Jobs laufen immer nach all diesen Aktionen oder sind nicht in der Lage solche Werte Dynamisch zu greifen. Um ein Formular (Firstname, Lastname, E-Mail) aus einem Body zu fischen musst Du IMHO programmieren.

GA beherrschen keine FollowUp Logik. Sie können nicht spezifisch Werte extrahieren und setzen und dabei ohne entscheiden, ist es ein FollowUp oder nicht. Sie müssen auch wieder auf das Event warten und arbeiten dann nachgelagert.

Dazu kommt das die mangelnden RegEx Felder den GA Job schlecht zu pflegen machen. Wenn ich 5 oder 6 Empfänger abfangen möchte muss ich 5-6 Jobs schreiben. Im PM Filter ist es ein Filter mit (Wert1|Wert2|Wert3), dazu werden auch noch Negierungen unterstützt.
Da sehe ich den Vorteil klar beim PMFilter.

Das war es dann jetzt auch zu dem Thema.

Gruß

[hkais]

Ich musste da jetzt erstmal ein wenig drauf rum denken. Und versuche hier jetzt mal so neutral wie möglich zu antworten um dir und den Mitlesenden zu erklären wo ich die Hauptunterschiede sehe und warum GA kein Ersatz sind.

Die Testbarkeit ist beim GA ungefähr genau so schlecht wie bei den PM Filtern. Du siehst ja in der Preview nur welche Tickets betroffen sind. Aber nicht was gemacht wird. Du musst ihn also zwangsweise ausführen um wirklich zu sehen was passiert.

NO-ACK
Ich sehe welche Tickets gegriffen werden, d.h. ob meine Suchkriterien korrekt sind. D.h. ich kann damit auch auf Historie (alte Tickets) zurückgreifen und prüfen, wäre die Suche denn für die alten Tickets korrekt gelaufen.
Das geht schlicht und ergreifend für PMF nicht

Wenn diese Prüfung getan wurde, kann man dann auf einzelne Tickets beschränken und dort ausprobieren ob der GA funktioniert. Auch das ist mit PMF nur schwerer erreichbar.
D.h. ich kann beliebige Tickets mal "clonen/splitten" und damit den GA nochmals ausprobieren... Und das alles als Endanwender ohne Admin/IT Expertise zu haben.

Deine Argumentation ergibt auch nur wirklich Sinn wenn Du kein Test System hast. Eine Testmail zu schicken bzw. in das System zu pipen, oder einen GA manuell auszuführen ist IMHO ein identischer Aufwand.

NO-ACK, es gibt Test-Systeme, die haben aber oft Constraints, wie:
- soviele Tickets können wir dort nicht aufschlagen lassen
- (Schnittstellen-)System gibt es nicht oder dürfen nicht verwendet werden
- oder oder oder

D.h. letztendlich muss der Finale-Test auf Production stattfinden. Dann ist die Frage vieler Power-User, warum überhaupt auf Test-Systemen ausführen, wenn ich mit dem GA jeden Zwischenschritt prüfen kann.

Zugegeben, der Import Export von PM Filtern ist im Moment nicht, ohne Addon, möglich das wird sich aber in der Zukunft ändern. Das ist ein Punkt den die GAs leider auch haben, aber für ein Staging ist also etwas manuelle Arbeit notwendig.

Full-ACK für PMF nicht möglich.
NO-ACK für den GA Teil. Mit GAs kann ich entweder über einen Split dieses herbeiführen, oder ich kann ganz einfach die Suchkriterien erweitern.

Was deine GA Logik, zumindest soweit es mir klar ist, nicht kann sind folgende essentielle Punkte:
- Filter arbeiten vor Autorespondern/Notifications
Wenn Du Ticket Notifications basierend auf Ticket Attributen nutzen willst, kommst Du mit dem GA Job nicht weit. Analog verhält es sich mit Sortierungen in Queues. Wenn Du z.B. nach Sprache sortierst und entsprechende Autoresponder schicken willst, brauchst Du einen Filter. Das kann der GA (wegen der Reihenfolge der Ausführung)
- Filter können Mails ignorieren (X-OTRS-Ignore) für Spam Tags zum Beispiel praktisch, wenn man nicht Herr des eigenen Mail Servers ist

Full-ACK
wie ich schon geschrieben hatte, für Spezialfälle verwenden wir auch PMFs. Und das sind alles sehr spezielle Fälle, da möchte ich auch keinen IT-Laien oder Power-User dran haben, sondern einen IT Experten. Der kann und soll sich dann auch mit PMFs rumschlagen.

- Filter können einzelne Werte, z.B. aus Formularen extrahieren und übernehmen. Auch so schöne Sachen wie Reply-To, CustomerID, CustomerNo usw.
GA Jobs laufen immer nach all diesen Aktionen oder sind nicht in der Lage solche Werte Dynamisch zu greifen. Um ein Formular (Firstname, Lastname, E-Mail) aus einem Body zu fischen musst Du IMHO programmieren.

Full-ACK
aber es wäre ein leichtes dieses ins Znuny mit aufzunehmen.
Z.B. ein Module welches als TransitionAction und als GA Module funktioniert.
Wie bereits geschrieben haben die Kollegen hier einiges entwickelt und sobald klar ist wie damit umgegangen wird, wird es gepublished.
Dann gehen genau auch diese Dinge die jetzt nicht gehen, dynamisch Werte aus Articels extrahieren und mit GAs automatisierbar. Mit PMFs, ne lieber nicht...
Hierfür wird dann auch via RegEx vieles möglich sein

GA beherrschen keine FollowUp Logik. Sie können nicht spezifisch Werte extrahieren und setzen und dabei ohne entscheiden, ist es ein FollowUp oder nicht. Sie müssen auch wieder auf das Event warten und arbeiten dann nachgelagert.

Partial-ACK
Jetzt kommt es darauf an, was genau als FollowUp bezeichnet wird.
Out of the box geht das nicht, aber wäre auch nicht sonderlich komplex das nachzuziehen.
Wir haben z.B. eine Erweiterung die es ermöglicht beliebige Werte aus dem Content zu extrahieren. Diese dann so bereitzustellen, dass ein Merge oder Link auf externen Merkmalen durchgeführt werden kann.

Dazu kommt das die mangelnden RegEx Felder den GA Job schlecht zu pflegen machen. Wenn ich 5 oder 6 Empfänger abfangen möchte muss ich 5-6 Jobs schreiben. Im PM Filter ist es ein Filter mit (Wert1|Wert2|Wert3), dazu werden auch noch Negierungen unterstützt.
Da sehe ich den Vorteil klar beim PMFilter.

Full-ACK
Out of the box nicht, daher haben wir hier auch etwas entwickelt. Allerdings hat Znuny 6.4 schon einige Bordmittel dafür da. Ein einfacher Invoker der eine TransitionAction ruft wäre magic schon für die Anforderung

Punkt um, wenn ich nun alle Aspekte zusammenfasse & nochmals bewerte, dass

• die meisten Anforderungen ähnliche Komplexität haben wie die von Marc geschildert
• diese Anforderungen ohne IT-Berater und IT Experten als GA umsetzbar sind
• damit eine breitere Personenzahl an den GAs mitwirken können
• und damit ein höherer Automatisierungsgrad zwangsweise aus den Fachbereichen kommt
• und vor allem sich keiner Sorgen machen muss, dass sein PMF Amok läuft da nicht alle Grenzfälle getestet wurden (mangels Historie)
• bei den GAs es nicht vorkommen kann, dass ein falscher RegEx massen an E-Mails und damit Tickets regelrecht unbrauchbar macht
• selbst bei fehlerhaften GAs, die Tickets immer noch "reparierbar" sind. Bei PMFs eben häufig nur mit massiv viel manuellem Aufwand
• die meisten Aspekte aus meinem vorherigen Post einfach link liegen gelassen wurden

gibt es für mich weiterhin nur eine klare Empfehlung:
Verwendet GenericAgents, lasst PMFs links liegen,
nur wenn ihr mit den GAs NICHT weiterkommt, geht auf PMFs

weitere Info:
Die Erweiterungen die entwickelt wurden, sind in Klärung. Es soll auch hier keine Werbung dafür sein. Bei passendem Anlass wird sicherlich darüber mehr erzählt und auch in welchem Modell diese veröffentlich werden. In Summe sind es aber Erweiterungen die die Vorteile der GAs ausbauen und die fehlenden Features aus den PMFs zu den GAs bringen. Womit die GAs nochmals deutlich besser nutzbar werden.

Was die Entwickler nicht verstehen, warum bei den GAs und den Modules einfach wenig bis gar nichts passiert. Transparenz seitens Znuny an dieser Stelle wäre sicherlich hilfreich (aber das Thema hatten wir im anderen Thread schon)

[Johannes]

Was die Entwickler nicht verstehen, warum bei den GAs und den Modules einfach wenig bis gar nichts passiert. Transparenz seitens Znuny an dieser Stelle wäre sicherlich hilfreich (aber das Thema hatten wir im anderen Thread schon)

Vielleicht weil wir nicht alles auf einmal machen können. So als ganz simple, transparente Antwort.