Umsteigerfragen

[Frank Niethardt]

Hallo,

durch Firmenwechsel bin ich neu zu KIX - in dem Fall die 18 - gekommen. Früher hatte ich mit diversen anderen nicht-OTRS Systemen zu tun. Daher stellen sich mir noch einige, teils konzeptuelle, Fragen. Ich hab zwar schon Doku gewälzt, und auch das Forum durchsucht, aber noch keine befriedigende Antworten gefunden:

• Gibt es einen besonderen Grund, warum bei Notizen ein Betreff verlangt wird? Bzw. kann man das deaktivieren?
  Notizen sind doch quasi Kommentare am Ticket - oder sehe ich das falsch?
• Ist es geplant, FAQs auch mit Kontakten verknüpfen zu können?
  Use Case ist quasi "Kontaktiere X (externe Firma), und fordere y an".
• Auch FAQ: Kann man diese "Problem - Lösung" Struktur aufbrechen? Beispielsweise, um allgemein Dokumentation dort hineinlegen zu können?
• Wie kann man Tickets mittels FAQs lösen?
• Auch von früher kenne ich die Variante: Ich stelle eine Rückfrage an den Betroffenen des Tickets und wenn dieser innerhalb von zwei Wochen nicht antwortet, wird das Ticket geschlossen. Lässt sich so etwas realisieren?
  Ich habe den ziemlich versteckten Mechanismus für das Auto Close beim Schließen von Tickets gefunden, aber der scheint mir nur einen Statusübergang zu kennen. Für das mit der Rückfrage bräuchte ich ja eher einen anderen, der signalisiert, was das Ticket gerade macht.
• Noch was eher nerviges: Wenn man mehrere Tabs in KIX offen hat, weil man beispielsweise aus einem abschreibt, und dann zwischen diesen hin und herwechselt, dann laden diese sich immer wieder neu. Dadurch setzen sich auch Größen für Textfelder und teilweise Scrollpositionen zurück. Ist das so gewollt? Kann man das beeinflussen?

So, das wär es fürs Erste. Bin für alle Hinweise dankbar.

Viele Grüße
Frank

[Frank Niethardt]

Bin ich hier an der falschen Stelle? Oder sind alle ideenlos?

[Beatrice Müller]

Hallo Frank,

zu deinen Fragen:

• Der Betreff soll eine kurze Zusammenfassung des Inhalts widerspiegeln. So hat man in langen Artikellisten einen besseren Überblick.
  In der Konfiguration der Aktionen/Vorlagen kann der Betreff auch mit Platzhaltern oder Text vorbelegt werden.
• In diese Richtung ist bisher noch nichts geplant. Mit einer detaillierteren Beschreibung (Anforderung, Use Case, Akzeptanzkriterien), kann eine UserStory dazu eingestellt werden.
• Der Rahmen für die FAQ-Einträge ist so vorgegeben. Es besteht aber die Möglichkeit nur die relevanten Bereiche (z.B. Lösung) zu füllen.
• Z.B über die Sidebar "Empfohlenen FAQ".
• Dafür gibt es mehrere Ansätze:
  
  • Der erste und einfachere Weg ist über den Statustyp "pending auto" und da gleich den Zeitraum von zwei Wochen einzustellen.
    In SysConfig "Ticket::StateAfterPending" müsste dazu dann noch automatische der Statusübergang definiert werden.
  • Der zweite Weg wäre über einen zeitgesteuerten Job. Dieser prüft dann z.B. auf "zuletzt geändert am" und kann über diverse Filter entsprechend eingeschränkt werden.
• Das haben wir bereits auf der Agenda. Ein zeitlicher Rahmen für die Anpassung lässt sich aber noch nicht nennen.

Viele Grüße
Beatrice

[Frank Niethardt]

Hallo Beatrice,

danke für die Antworten.

4. oh, das ist aber gut versteckt.
Bei verschiedenen Aktionen taucht dort dann ein Extra Symbol auf, um die Texte in einen "Artikel" zu übernehmen. Wenn man jetzt aber beispielsweise im ITIL Paket, Incident in "Lösen" ist, dann gibt es zwar das Symbol in der Seitenleiste, aber es hat keinen Effekt, weil in der Aktion kein Artikel enthalten ist, sondern ein eigenes Feld für die Lösungen...
Das ist IMHO noch nicht ganz zu Ende gedacht...

5. das probier ich mal aus... Gibt es da sowas wie "aktuellen Status" auslesen und auch wieder setzen, wenn Antworten eintrudeln?

7. Gibt es bei Tickets auch eine Möglichkeit wie "warten auf Subtickets", also wenn man Nachfolge/Kind-Tickets erstellt und dann warten will, dass die geschlossen sind?

Viele Grüße
Frank

[Beatrice Müller]

Hallo Frank,

zu 5.) wenn ein Statusworkflow verwendet wird, kann über den SysConfig-Schlüssl "TicketStateWorkflow::PostmasterFollowUpState" der Platzhalter _PREVIOUS_ verwendet werden

zu 7.) das haben wir bereits auf der Agenda - ich habe deinen Bedarf an der User-Story ergänzt

Viele Grüße
Beatrice

[Frank Niethardt]

Hallo Beatrice,

ich bin gerade dabei das mit der Rückfrage zu konfigurieren. Ein Teil funktioniert schon ganz gut, nur das mit dem Statuswechsel bei Antworten macht mir noch ein wenig Kopfzerbrechen.
Wenn ich das mit dem PostmasterFollowUpState richtige verstehe - wohlgemerkt KIX18 Pro - dann kann man da genau einen Status hinterlegen, bzw. mit _PREVIOUS_ erzwingen, dass er einen Status zurück geht. Das scheint ja global zu greifen. Sprich, immer wenn eine Mail von außen an das Ticket kommt, setzt er den Status, der eingestellt ist, oder geht einen Status zurück.

Da ich ja nicht bestimmen kann, wann jemand etwas von außen schickt, und die Einstellung ja auch global ist, ist es ziemlich ungeschickt, dort _PREVIOUS_ zu setzen. Andererseits sind in anderen Prozessen die Statuswechsel in einen festen Status durch eingehende Mails auch nicht unbedingt gewollt. Standard ist hier "open". Das stört z.B. die Prozesse im mitgelieferten ITIL Paket.

Kann man den Statuswechsel vielleicht komplett deaktivieren und dann über Eventgesteuerte Jobs durchführen?

Viele Grüße
Frank

[Frank Niethardt]

Ok, wieder einen Schritt weiter. Es war nicht PostmasterFollowUpState, sondern TicketStateWorkflow::PostmasterFollowUpState gemeint. Dort kann ich dann sagen, dass es, wenn es in "Kundenrückfrage" ist in "_PREVIOUS_" gehen soll. Das klappt auch sehr gut.

Scheinbar nimmt KIX aber für alle anderen Status, die dort nicht definiert sind, den Wert von PostmasterFollowUpState. Der ist per default "open" und lässt sich auch nicht deaktivieren.

Daher nochmal die Frage: lässt sich der automatische Wechsel für nicht in  TicketStateWorkflow::PostmasterFollowUpState definierte Status deaktivieren?

[Beatrice Müller]

Hi Frank,

der automatische Stauswechsel lässt sich nicht deaktivieren.
Dies soll verhindern, dass Kundenrückmeldungen unter gehen.
Es müssten also alle relevanten Übergänge definiert werden.

Sollte es keinen "_PREVIOUS_"-Status geben, müsste außerdem der Schlüssel "TicketStateWorkflow::FallbackForPreviousState" angepasst werden.

Eine Ausnahme wäre noch der Header 'X-KIX-FollowUp-KeepState'. Sobald dieser in der Mail enthalten ist, findet kein Statuswechsel statt.
Das wäre dann ein Anwendungsfall für interne Mails/Tools.

Viele Grüße
Beatrice

[Frank Niethardt]

Moin,

ich antworte mal auf meine eigene Frage:

FAQ: Kann man diese "Problem - Lösung" Struktur aufbrechen? Beispielsweise, um allgemein Dokumentation dort hineinlegen zu können?

In der SysConfig gibt es FAQ::* Schlüssel, in denen man die Überschriften und Sichtbarkeiten festlegen kann. Dort sind sogar sechs statt vier Felder vorgesehen...

Viele Grüße
Frank