[otobo user]

Hallo zusammen,

nachdem ich jetzt schon einiges ausprobiert und sowohl die Docs als auch das Forum durchforscht habe, bleibt mir wohl nur noch, selbst ein Topic aufzumachen.

Ich habe ein dynamisches Feld erstellt und lasse es in den Screens CustomerTicketMessage und AgentTicketNote anzeigen. Über ACLs schränke ich dann ein, dass es nur in einer bestimmten Queue angezeigt werden soll. Bei der CustomerTicketMessage funktioniert das auch ganz prima, nur bei der AgentTicketNote ist das Feld immer noch zu sehen.

Ich habe testweise mal diese ACL angelegt, die ja wirklich alle Felder verstecken sollte. Leider ist mein dynamisches Feld immer noch sichtbar. Habe ich hier einen Denkfehler? Mache ich etwas falsch?

Schon einmal danke und Grüße

[Stefan Garthe-Draht]

Ich lehne mich mal aus dem Fenster und vermute, dass ACLs nicht auf AgentTicketNote angewendet werden.

Wir haben ein DynamicField für die externe Ticketnummer eines Dienstleisters. Das Form möchte ich nur haben, wenn ein bestimmter Service ausgewählt ist und das klappt so:

Wir haben eine ACL die generell alle DynamicFields immer ausblendet. Auch wenn sie über DF Oberflächen einer Action zugeordnet sind. Wenn ich dann wirklich ein Form sehen will, steuere ich das über PossibleAdd.

Ich habe eben testweise die ACL für jenes Form um AgentTicketNote ergänzt und habe das DF in den Oberflächen der Action auch zugewiesen. Das Ergebnis: Auch ich sehe das Form überall, das Match Settings hätte auf den einen Service einschränken müssen. Meine Erwartung wäre gewesen, dass es nur beim gewünschten Service greift.

Insgesamt finde ich das aber eine sehr schöne Idee und werde mal damit spielen, bei welchen Aktionen ich dieses Form in dem Service noch präsentieren kann. Danke für die Inspiration!

 

[otobo user]

Hallo Stefan,

danke für deine Nachforschungen, ich hatte schon befürchtet, dass die ACLs dafür einfach nicht greifen.

Prinzipiell suche ich nur einen Weg, wie Agents die Werte von DFs korrigieren können, wenn die Customer etwas nicht richtig angegeben haben. Die AgentTicketNote schien mir ein guter Ort dafür, aber auch nur, wenn ich meine 20+ DFs einschränken kann, damit auch nur die Felder gezeigt werden, die für das Ticket relevant sind.

Aber vielleicht gibt es auch einen besseren Weg, die Werte der DFs anzupassen?

[Stefan Garthe-Draht]

Nichts leichter als das: Action=AgentTicketFreeText ist Dein Freund! Also das gute alte „Ticket kategorisieren“.

Dort passen wir bei uns nachträglich als Agent DFs an, die für das Ticket relevant sind und entweder nicht passend vom Kunden befüllt wurden oder die wir selbst nachträglich eingeben. Hier ist meine Lösung:

1.  ACL blendet ALLE DFs überall aus (wir haben 300+ DF im System)
2. Neue DF erstellen. Hier: Bugzilla Nummer eines Dienstleisters (Kann man später auch anklicken im System)
3. DF Oberfläche zuweisen:
   1. AgentTicketPhone, AgentTicketEmail um die Nummer beim Anlegen eines Tickets als Agent gleich zu einzutragen
   2. AgentTicketFreeText für die Nachträgliche Anpassung über „Ticket Kategorisieren“
   3. AgentTicketZoom, damit das DF rechts in den Ticketinfos auftaucht und hier ein klickbarer Link zum Bugzilla des Dienstleisters ist (nur Anzeige, nicht bearbeiten)
4. ACL erstellen, die dieses DF nun wirklich in den genannten Actions mit PossibleAdd hinzufügt. Die Bedingung ist hier der Service, dem dieses Ticket zugeordnet ist. Könnte man aber auch anhand der Queue machen. Oder einfach ohne Bedingung, aber eben nur in den genannten Oberflächen/Actions.

Ich bin gerade nicht sicher, ob sich das „Ticket kategorisieren“ per default unter „Verschiedenes“ bei der Ticketbearbeitung „versteckt“. Es ist möglich, dass wir das bei der Einrichtung des Systems da rausgenommen haben und es nun in der Reihe neben „Sperren“ und „Personen“ angezeigt wird. Wenn das so ist, kann ich nachschauen, wie das geht.

Das war es auch schon. Ich hoffe, es ist verständlich…

 

[otobo user]

Danke für den Hinweis und die kleine Anleitung, leider scheinen die ACLs hier aber auch nicht zu greifen. Gibt es noch eine andere Konfiguration, die ich erst anpassen muss?

(Das Feld müsste ja eigentlich ausgeblendet sein, oder nicht? ACLs sind deployed)

OTOBO Docker Version 11.0.10

[Stefan Garthe-Draht]

Vielleicht einmal die RegExp ohne *? Und wirf das leere „[+] Ticket“ aus dem PossibleNot Block. Ansonsten schaut es plausibel aus.

Ich würde die Logik wirklich umdrehen von bei Euch „Alle anzeigen und stellenweise ausblenden“ auf „Alle ausblenden und stellenweise anzeigen“. Ich packe mal Screenshots von uns rein, für Eure Logik müsstest Du es „umdrehen“.

1. ACL blendet ALLE DFs an ausfüllbaren/interaktiven Stellen aus
   1. 
2. DF Oberfläche zuweisen
   1. 
   2. (AgentTicketZoom blenden wir weder ein noch aus. Das wird nur über die Oberflächen gesteuert.)
3. ACL erstellen, die dieses DF nun wirklich in den genannten Actions mit PossibleAdd hinzufügt.
   1. 
   2. (CustomerTicketMessage ist mit drin, weil User selbst auch Tickets beim Dienstleister auslösen könnten. Nicht elegant, aber teilweise nötig.)
4. Voila
   1. 

Diese Logik hat den Vorteil, dass Du eben nur an der Stelle ein Feld einblendest, wo du es haben willst. Also 1 Feld = 1 Aufwand. Wenn Du für das Anzeigen von einem Feld an einer Stelle an allen anderen Stellen alle anderen Felder ausblendest, die du nicht haben willst, hast du ( Anzahl_DF-1 * Anzahl_Ausblendungen ) Aufwand… Das ist bei 20 Feldern noch zu verkraften, aber würde mich bei 300 in den Wahnsinn treiben. (Und das tun komplexe Formulare mit mehreren DF und ACL auch so schon genug)

• Diese Antwort wurde vor 4 Tagen, 1 Stunde von Stefan Garthe-Draht geändert.
• Diese Antwort wurde vor 4 Tagen, 1 Stunde von Stefan Garthe-Draht geändert.

[Autor]

Beiträge