Aktionen für mehrere Tickets durchführen

[Frank Niethardt]

Hallo,

aktuell gibt es in KIX ja die Sammelaktion, die auf sehr technischer Ebene für mehrere Tickets gleichzeitig Felder, Status und mehr setzen kann. Problem daran ist eben das "sehr technisch".

Wenn man eher prozessorientiert arbeitet, dann gibt es Fälle - bei uns sind es die Schwachstellentickets - bei denen man gern auf fachlicher Ebene Dinge mit den Tickets machen möchte. 

Beispielhaft: neue Chrome-Version wurde auf alle Maschinen ausgerollt -> Alle betreffenden Tickets können geschlossen werden. 
das heißt technisch:

• DF CloseCode auf "Schwachstelle behoben - Update installiert"
• DF Letzter Bearbeiter auf <KIX_CURRENT_UserID>
• Status auf "geschlossen"

und fachlich:

• Ticket öffnen
• Aktion Schließen
• Close Code auswählen / so lassen
• Status Auswählen / so lassen
• bestätigen

Beim Fachlichen können wenig Fehler gemacht werden und es ist für alle Verständlich. Beim Technischen kann man quasi alles falsch machen. Insbesondere bei dem "Letzten Bearbeiter" habe ich so meine Zweifel, dass der immer korrekt befüllt werden wird... ;)

Lange Rede, kurzer Sinn - es wäre gut, Tickets anhaken zu können, und eine Art fachliche Sammelaktion zu haben. Die Schnittmenge, der zur Verfügung stehenden Ticketaktionen, beispielsweise...

Viele Grüße
Frank

[Torsten Thau]

Hallo Frank,

ich denke wir haben eine Story die das Szenario gut abdecken dürfte. Leider ist diese noch nicht eingeplant. Ich bin aber so frei und trage Euch in den interessierten Kunden ein. Das hier ist die Anforderungsfomulierung:

KIX2018-12571 - Object Action :: Sidebar "Auch anwenden auf ähnliche Tickets"

• Als Agent habe ich häufig ähnliche Aufgaben an mehreren Tickets zu erledigen (z.B. bei Wartungen) und kann in der Sammelaktion diese nicht immer ausführen (keine Notiz-/Email-Möglichkeit) oder muss die Tickets selbst zusammensuchen. Das dauert zu lang.
• Aus einem Ticket heraus wird eine Object Action geöffnet. In einer Sidebar stehen "ähnliche Tickets" zur Selektion zur Verfügung. Mit Speichern der Aktion werden alle Änderung am aktuellen Ticket auch auf die ausgewählten "ähnlichen" Tickets angewandt.
• "Ähnlich" soll dabei konfigurierbar sein, aber ootb folgenden Kriterien genügen: gleicher Bearbeiter, gleicher Typ, gleiches Team, gleicher Status, gleiche AffectedServices.

Eine Alternative zur Entwicklung, welche heute bereits realisierbar ist, ist die Abbildung über einen "Master-Slave"-Automatismus. Dabei wird eines der Tickets zum "Master" erklärt. Dieser erhält alle anderen als Kindtickets zugeordnet. Ein Job, der ggf. nur bei ausgewählten Services oder Typen wirkt, wendet nun alle für den Fall relevanten Änderungen am Master auch auf die Slave-Tickets an. In Deinem Szenario: DF CloseCode, DF LastOwner, StateUpdate. Heute (12/2024) ist das der Weg den ich empfehlen würde.


Viele Grüße und eine schöne Weihnachtszeit sowie einen guten Start in 2025, Torsten

[Frank Niethardt]

Moin Torsten,

die Story wäre glaube hilfreich. Das Master-Slave Szenario passt in unseren konkreten Anwendungsfällen eher selten.

Danke, und wünsch ich dir auch.

Grüße Frank