Bearbeiter sieht Ticket nicht

[littledirk]

Wenn wir ein Ticket erstellen und keinen Bearbeiter direkt zuweisen, wird automatisch der Ticketersteller als Bearbeiter eingetragen. Das ist in Ordnung. Nur sieht dieser das Ticket nicht wenn es nicht in seiner Queue abgelegt ist, da es noch den Sperrstatus offen hat.
Gleiches gilt wenn jemand ein Ticket wieder frei gibt. Er sieht es dann standardmäßig nicht mehr im Dashboard obwohl er noch als Bearbeiter zugewiesen ist.
Für uns bedeutet das, dass der Bearbeiter zwangsläufig immer auch die Queue abonniert haben muss, obwohl man ihm auch Tickets zuweisen kann die nicht in einer von ihm abonnierten Queue abgelegt sind.
Haben wir hier einen Denkfehler? Wie können wir dem Agenten auch die Tickets im Dashboard anzeigen lassen, welche nicht in von ihm abonnierten Queue liegen, denen er aber als Bearbeiter zugewiesen ist?

[Tino Voigt]

Hallo,

hier scheint es ein Problem bei den Berechtigungen auf einzelne Queues zu geben.  Wenn der Bearbeiter keine Berechtigung auf eine bestimmte Queue besitzt, werden Ihm keine Tickets dieser Queue angezeigt.
Können Sie einen Screenshot der Berechtigungen und den Namen einer betroffenen Queue mit der dazugehörigen Rolle posten?

Viele Grüße, Tino Voigt

[marceladm]

Du könntest dir eine Suchvorlage bauen, die die gewünschten Tickets anzeigt. Filterung nach Bearbeiter z.B. oder zusätzlich dem Sperrstatus.
Diese Suchvorlage kannst du dann dauerhaft im Dashboard einblenden lassen.

MfG


marceladm

[Sebi]

@marceladm Nach soetwas suche ich, allerdings bekomme ich es nicht eingestellt.


Ich hätte gern im Dashboard ein Dashlet, in dem jeder Agent, alle Tickets sieht dessen Bearbeiter er ist (unabhängig vom Sperrstatus).
Gibt es dazu irgendwo Beispielkonfigurationen?

Unter Ticket->Frontent::Agent::Dashboard gibt es ja DashboardBackend###0901-SearchTemplate01
Das sieht aus, als wäre es das, allerdings finde ich keine informationen wie ich dort die Filter usw richtig verwende.
"Attributes" sind wie ich es gesehen habe eher statische Filter (Ticket Status, Queue, usw) da es sich ja an den Agenten anpassen muss, bräuchste ich ja soetwas wie Systemvariablen, oder?
Ausserdem gibt es ja auch noch "Filter" der scheinbar überall nur auf ALL steht.

[DieListe]

das muss jeder Agent für sich selber einstellen:

   
• Suchvorlage basteln
• Auf dem Dashboard rechts oben "Einstellungen" aufklappen, und dann eine freie Suchvorlage anhaken
• dem neuen "Dashlet" auf dem Dashboard die eben erstellte Suchvorlage zuordnen
• fertig

[Sebi]

Das ist sehr ungünstig. Es sind sehr viele Agenten und auch nicht immer besonders Fit im Bezug auf Technik. Ich würde daher gern die Ansicht so einfach wie möglich gestalten und auch schon optimiert vorgeben, daher habe ich gehofft das gleich global einstellen zu können. Keine Alternative?

[marceladm]

Du kannst die Suchvorlage auch in eine Gruppe aufnehmen und bei den Userprofilen der Agenten dann diese Gruppe auswählen. Dann hat jeder gleich die Suchvorlage zur Verfügung.
Aber die Auswahl im TicketOverview rechts über die Einstellungen muss der Agent selber tätigen.
Wenn er das Dashlet dann ausgewählt hat, kann er es editieren und hat dann aber schon die Suchvorlage zur Verfügung.

[Sebi]

Ja das klingt schon besser. Wo finde ich denn die entsprechenden Masken dazu? Wenn ich eine Suchvolage ganz normal definiere, muss ich explizit einen Bearbeiter auswählen und wildcards bringen mich ja auch nicht weiter. Zudem finde ich auch nirgends einen Menüpunkt zum verknüpfen von Suchvorlagen und Gruppen. Vllt ich der Notwendige Sysconfig Eintrag nicht gesetzt?

[DieListe]

das kannst du beim definieren der suchabfrage einstellen

[Sebi]

Ja, das habe ich gemacht aber unten hast du ja sicher als Agent dich selbst ausgewählt, da müsste ja dann aber eine Variable rein, sowas wie $self->current::agent oder so, sodass es immer den Agenten nimmt, der die Suche ausführt, sonst muss ich ja für jeden Agent ne eigene Abfrage erstellen. Und wie ich diese Suchvorlage an bestimmte Gruppen hänge fehlt ja, so ist ja jede Suchvorlage für jeden freigegeben.

[marceladm]

Du musst für jeden Agenten eine eigene Vorlage haben das ist korrekt. Die einzige Arbeit die du sparen kannst, ist den anderen Agenten das nicht zu erklären. Du könntest die Gruppe anlegen, für jeden Agenten die SuVo erstellen und dann können die anderen Ihre auswählen.

[DieListe]

Die Frage ist: ist die Denke richtig? Ich bin erst Bearbeiter eines Tickets wenn das Ticket auch gesperrt ist. Denn ich kann auch ein Ticket in eine andere Queue schieben und bin dann Bearbeiter obwohl ich mit dem Ticket nichts zu tun habe.

Ich sehe das schon immer so:

Ticket ist nicht gesperrt dann ist einfach der aktuelle Bearbeiter nur der, der als letztes das Ticket angefasst hat. Egal ob er zuständig ist für das Ticket oder nicht. Erst wenn das Ticket auch auf ihn gesperrt ist, dann ist er auch wirklich der aktuelle Bearbeiter der dran arbeitet.

Dann braucht man aber keine extra Suchvorlage, sondern kann die Toolbar nutzen die anzeigt ob, und wenn ja wieviel Tickets ich gerade bearbeite / in der Verantwortung habe.

OK?

[marceladm]

Ich denke das wäre auch ein Weg. Ich finde das eher komplizierter. Aber das ist eben eine andere Herangehensweise, die man unter sich zur Umsetzung kommunizieren muss.

[DieListe]

Das haben wir auch lange versucht aus den Köpfen zu bekommen. Also Bearbeiter / (OTRS: Besitzer) ist man erst für ein Ticket verantwortlich wenn dieses auch für den Agenten gesperrt ist.
Des weiteren besteht am anfang imer die Verwechslung zw. Bearbeiter und Verantwortlicher. Wie alle im Team hätten längst die Namen ausgetauscht.

Wir:
Verantwortlicher - Head of Ticket - er hat die Verantwortung über alles was am Ticket passiert
Besitzer: Wechselt ständig - der der gerade as ticket im Besitz hat muss was daran machen.

OTRS/KIX: genau andersrum.

Aber mittlerweile haben wir uns an die Begriffe gewöhnt :-)

Daher wirklich mein Vorschlag: Setzt den Bearbeiter erst, wenn ihr das Ticket für jemanden sperrt.

[marceladm]

Wir arbeiten z.B. ohne den Verantwortlichen.
Ich habe einen Benutzer angelegt der "nicht zugewiesen" heißt und dann der Verantwortliche ausgeblendet wird. Der Benutzer wird im Hintergrund einfach gesetzt.
Wir arbeiten dann aktiv über den Bearbeiter und das ausschließlich.
So gibt es eben unterschiedliche Arbeitsmethoden. Das finde ich stimmt KIX sehr gut auf den Einzelnen ab.