
Was bedeutet der Punkt sperren unten in der Ansicht? Wenn ich einen neuen Fall anlege und einem Benutzer zuweise ist der doch sowieso gesperrt oder?
Mit 'Sperren' sperrst Du das Ticket für Dich, nicht für jemand anderen. Danach steht das Ticket so lange nicht mehr anderen Agenten in der QueueView zur Verfügung, bis Du selber oder ein Automatismus es freigibst.
Das verstehe ich noch nicht. Wenn ein Fall neu aufgenommen wird und ich einen Bearbeiter zuweise heisst das dann das der Fall nicht automatisch gesperrt ist?
Hallo Jürgen, kann ich vielleicht auch was zu sagen, Ich denke es gibt hier verschiedene Strategien. Wenn jeder Agent in einer Queue alleine bestimmte Bereiche abdecken soll, macht es Sinn, diese sofort automatisch für ihn sperren zu lassen. Was machst du aber , wenn dieser Agent krank ist, Urlaub hat...etc. Im allgemeinen hast du dann keine Kontrolle über diese Tickets, da sie ja nur für diesen einen Agenten sichtbar sind. Wir hier bei uns haben mehrere Agenten pro Queue. Alle neu erstellten Tickets werden als ungesperrt ohne Agentenzuweisung in die Queues zugewiesen. Dabei ist für uns das neue Feature - sperren, nicht sperren - bei der Ticketanlage durchaus sinnvoll, weil wir eben nicht automatisch Tickets gesperrt haben wollen. Und wenn hier jeder sein System anders benutzt, muß der (die) Entwickler entsprechend reagieren und dies als Option anbieten. Viele Grüße Jonas

Jonas Wendland schrieb:
kann ich vielleicht auch was zu sagen, Warum nicht :-)
Ich denke es gibt hier verschiedene Strategien. Wenn jeder Agent in einer Queue alleine bestimmte Bereiche abdecken soll, macht es Sinn, diese sofort automatisch für ihn sperren zu lassen. Was machst du aber , wenn dieser Agent krank ist, Urlaub hat...etc. Im allgemeinen hast du dann keine Kontrolle über diese Tickets, da sie ja nur für diesen einen Agenten sichtbar sind.
Da gebe ich dir Recht aber.... Wenn ich ein Ticket erstelle und es nur einer Queue aber keinem Benutzer zuweise sollte das Ticket nicht gesperrt werden. Dies entspricht dem Aufschlagen eines Tickets per Mail. Wenn ein Bearbeiter eingetragen wird sollte das Ticket allerdings gesperrt werden (dies ist sinvoll da man in der Queuübersicht nicht sehen kann das das Ticket bereits von einer Person zugewiesen wurde). -- Mit freundlichen Grüßen Jürgen Meurer ---------------------------------------------------- BAD GmbH Herbert-Rabius-Str. 1 53225 Bonn Tel: 0228/40072-70 Email: meurer@bad-gmbh.de

On Tuesday, March 16, 2004 12:22 PM
Juergen Meurer
Wenn ich ein Ticket erstelle und es nur einer Queue aber keinem Benutzer zuweise sollte das Ticket nicht gesperrt werden. Dies entspricht dem Aufschlagen eines Tickets per Mail.
Wie gesagt, auch das ist nicht fest, sondern hierüber einstellbar, wie Du's magst: $Self->{EmailDefaultNewLock} = 'unlock';
Wenn ein Bearbeiter eingetragen wird sollte das Ticket allerdings gesperrt werden
Nur, weil das Ticket einem Agenten zugeordnet ist, muss es eben nicht gesperrt sein - das sind zwei verschiedene Paar Schuhe. Ein Agent kann nur ein Ticket sperren, das ihm bereits gehört, _muss_ das aber nicht tun.
(dies ist sinvoll da man in der Queuübersicht nicht sehen kann das das Ticket bereits von einer Person zugewiesen wurde).
Auch das ist einstellbar, die Variable heisst $Data->{Owner}, zu verwenden in den .dtl Dateien des jeweiligen Themas. Im Standard-Thema findet sich in TicketView.dtl ab Zeile 101 dies: # <tr valign="top"> # <td><b>$Text{"Owner"}:</b></td> # <td>

Robert Kehl schrieb:
Auch das ist einstellbar, die Variable heisst $Data->{Owner}, zu verwenden in den .dtl Dateien des jeweiligen Themas. Im Standard-Thema findet sich in TicketView.dtl ab Zeile 101 dies: # <tr valign="top"> # <td><b>$Text{"Owner"}:</b></td> # <td>
$Quote{"$Data{"Owner"}","18"}</div></td> # </tr>Ach ich liebe OTRS immer mehr. /Träum ein Man hat die Zeit (und das Verständnis) sich die ganzen Konfiguarationsdateien mal in Ruhe anzusehen. /Träum aus -- Mit freundlichen Grüßen Jürgen Meurer ---------------------------------------------------- BAD GmbH Herbert-Rabius-Str. 1 53225 Bonn Tel: 0228/40072-70 Email: meurer@bad-gmbh.de
participants (3)
-
Jonas Wendland
-
Juergen Meurer
-
Robert Kehl