January 2004 - otrs-de - OTRS mailing lists

Re: [otrs-de] GenericAgent -> escalation
by Lars Monsees 12 Jan '04

12 Jan '04

>> Problem ist im Moment noch, dass Tickets, die einmal beantwortet >> wurden (und das ist der Standard wenn man eine Antwort erstellt) in >> der DB entsprechend als beantwortet markiert werden. Diese werden >> aber anscheinend nicht beachtet, wenn auf eskalierte Tickets geprüft >> wird (weder Frontend noch GenericAgent). > >Das ist das beabsichtigte Verhalten. Ein Ticket gilt dann nicht mehr als >eskaliert, wenn es bearbeitet wurde, z.B. ein neuer Pending-State >vergeben wurde, oder eine Antwort versandt. Danach schlummert ein Ticket >gerne bis in alleEwigkeiten, ohne je wieder zu mucken. > Müsste ich also per Job alle Tickets auf "nicht beantwortet" setzen? >hth, > >Robert Kehl Lars

1 0

Re: [otrs-de] GenericAgent -> escalation
by Lars Monsees 12 Jan '04

12 Jan '04

>> Problem ist im Moment noch, dass Tickets, die einmal beantwortet >> wurden (und das ist der Standard wenn man eine Antwort erstellt) in >> der DB entsprechend als beantwortet markiert werden. Diese werden >> aber anscheinend nicht beachtet, wenn auf eskalierte Tickets geprüft >> wird (weder Frontend noch GenericAgent). > >Das ist das beabsichtigte Verhalten. Ein Ticket gilt dann nicht mehr als >eskaliert, wenn es bearbeitet wurde, z.B. ein neuer Pending-State >vergeben wurde, oder eine Antwort versandt. Danach schlummert ein Ticket >gerne bis in alleEwigkeiten, ohne je wieder zu mucken. > Müsste ich also per Job alle Tickets auf "nicht beantwortet" setzen? >hth, > >Robert Kehl Lars

2 1

OTRA Neuling
by Daniel Mauch 11 Jan '04

11 Jan '04

1 0

Statistiken
by Jens Bothe 09 Jan '04

09 Jan '04

Hallo, wir würden gerne ein paar Statistiken haben (außer den Grafiken): - Anzahl der Tickets pro Tag/Woche/Monat/Jahr - Status der Tickets (erfolgreich/nicht erfolgreich) - Tickets pro Bearbeiter - Tickets pro Queue Gibt es da zufälligerweise schon was brauchbares? Grüße Jens -- Deutsche Lebens-Rettungs-Gesellschaft e.V. - Präsidium Jens Bothe Arbeitskreis Internet E-Mail: bothe(a)dlrg.de http://www.dlrg.de

2 1

RE: [otrs-de] GenericAgent -> escalation
by Lars Monsees 09 Jan '04

09 Jan '04

> > Lösung: > > - UnlockTickets.pl unter neuem Namen abspeichern (damit es beim > > nächsten Update nicht überschrieben wird) und anpassen > > - Bisherigen Job so anpassen, dass am Ende ein Kommando > ausgeführt > > wird (UnlockTickets.pl starten) > > > > Ist das ok oder habe ich noch nen Denkfehler drin? > > You're on GO. ;-) > Fummelkram =) Läuft aber nun eigentlich so weit. Problem ist im Moment noch, dass Tickets, die einmal beantwortet wurden (und das ist der Standard wenn man eine Antwort erstellt) in der DB entsprechend als beantwortet markiert werden. Diese werden aber anscheinend nicht beachtet, wenn auf eskalierte Tickets geprüft wird (weder Frontend noch GenericAgent). Ich habe keine Einstellung in der Defaults.pm gefunden, mit der man dieses Verhalten steuern könnte... Was tun?

2 1

AW: Re: [otrs-de] Datenbank Grösse im Laufe der Zeit
by Oliver.Clouth＠swisslife.de 09 Jan '04

09 Jan '04

Hallo.. Kann man das evt. über einen delete job machen ? Wenn man TicketID's mit JahrMonatTagXY hat, könnte man doch z.b. 200301* übergeben und alle Tickets vom Januar 2003 werden gelöscht. Ich habe es noch nich probiert, da ich auch garnicht weiss ob man die TicketID so mit übergeben kann, aber hier der Job wie ich ihn jetzt so machen würde. ------- # -- # [name of job] -> close and delete all tickets in queue delete # -- 'delete' => { # get all tickets with this properties TicketID => '200301*', States => ['closed successful'], Locks => ['unlock'], # new ticket properties (no option is required, use just the options # which should be changed!) New => { # DELETE! Delete => 1, }, }, ------- Gruss Oliver Clouth > -----Ursprüngliche Nachricht----- > Von: robert.kehl [mailto:robert.kehl@otrs.de] > Gesendet am: Freitag, 9. Januar 2004 00:23 > An: otrs-de > Betreff: Re: [otrs-de] Datenbank Grösse im Laufe der Zeit > > On Thursday, January 08, 2004 7:01 PM > stephan.reichenbach(a)epost.de <stephan.reichenbach(a)epost.de> wrote: > > Am 8 Jan 2004 um 16:43 hat Michael Mauel geschrieben: > > > >> Hallo, > >> > >> ich denke mal das im Laufe der Zeit die Datenbank recht > gross werden > >> wird, zumal es > > auch pasiert das im heutigen Zeitalter viele Ihre > > Fehlerbeschreibungen doch mit > > Gallerien von Digitalen Bildern schmücken, um so dem Supportler > > möglichst > > anschaulich das Problem darzulegen. > > Was ja auch vollkommen o.k. ist - die Technik muss sich mMn > nach unseren > Bedürfnissen richten, und wenn dazu das Verschicken von Screenshots > gehören kann - her damit. Immer noch besser, als wenn Frau > Müller-Lüdenscheidt mir einen OTRS-Screen via Text "beschreibt"... > > Grundsätzlich ist dies ein Problem, dass eher auf MySQL-Basis gelöst > werden sollte. Das simple Löschen der Datensätze sollte mMn als letzte > Lösung in Betracht gezogen werden (wenn dem nichts Gesetzliches > entgegensteht bspw.). > > Um den Datenbanken (MySQL wie PostgreSQL und natürlich vor > allem Oracle) > ad hoc mehr Platz zu schaffen, gilt es, das Verteilen der > Datenbestände > auf die verschiedenste Speichersysteme zu erlauben, angefangen von > einfachen, eingehängten (man mount) Festplatten, über (immer > empfehlenswerte) RAID-Systeme bis hin zu Storage Area Networks (SAN). > > Jedes DB-System bietet entweder direkte Unterstützung einer wie immer > gearteten Art der verteilten Datenhaltung, oder kommt mit > unterliegenden > Szenarien mit NFS, DFS & Co. "zurecht". Bei Bedarf steht die > ((otrs.de)) > sehr gerne beratend zur Seite - http://www.otrs.de/ > > > als vorgabe habe ich, dass alle tickets die aelter sind als x-jahren > > (2 bzw 3) muessen entfernt werden. > > Sehr vernünftige Einstellung für eine Behörde. > > >> Gibt es einen Agenten, welcher Daten nach einstellbarer Zeit (x > >> Monaten, x Jahren > > etc.) aus der Datenbank löscht? > >> Irgendwie muss man ja auch mal von den Altlasten wieder > loskommen... > > ja, das wuerde mich brennend interessieren > > > Nein, leider zurzeit noch nicht. Gerne übernimmt die ((otrs.de)) aber > auch dergestalte Aufgaben. > > Robert Kehl > > -- > ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg > http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 > > _______________________________________________ > OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ > Archiv: http://lists.otrs.org/pipermail/otrs-de/ > Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ > Support oder Consulting fuer Ihr OTRS System? > => http://www.otrs.de/ >

4 3

Agent-Preferences >> Custom queues / Gruppe "users"
by Kleffmann. David 09 Jan '04

09 Jan '04

Hi zusammen, ich habe eine Frage zu den Custom-Queues, die ein Agent als "Favoriten" setzen kann (OTRS-Version 1.1.3). Wir hatten hier das Problem, dass die Agenten nur eine leere Liste zur Auswahl bekommen haben. Nachdem ein wenig Rumprobiert, habe ich festgestellt, dass hier nur Queues angezeigt werden, wenn der Agent in der Gruppe "users" gesetzt ist. Sofern ich das allerdings mache, hat jeder User alle Queues zur Auswahl, und nicht nur die, in deren Gruppen er eingeteilt ist. Ist diese Funktionalität so gewollt? Grüße, David Kleffmann

2 1

Unlook Tickets
by Thomas Hinz - Hetzner Online AG 09 Jan '04

09 Jan '04

Hallo, gibt es die Möglichkeit in OTRS Tickets die gesperrt wurden vom System bzw. von einem Bearbeiter, dass diese wenn sie der Besitzer in eine andere Queue verschiebt, automatisch vom System auf den Status frei gesetzt werden?? Ich weiß zwar, dass man dies via Cron Job erledingen kann, allerdings möchte ich die Anzahl meiner Cron Jobs so gering wie möglich halten!! MFG Thomas

2 1

RE: [otrs-de] GenericAgent -> escalation
by Lars Monsees 09 Jan '04

09 Jan '04

> > > On Friday, January 09, 2004 2:33 PM > Lars Monsees <l.monsees(a)atlantisgmbh.de> wrote: > > Lösung: > > - UnlockTickets.pl unter neuem Namen abspeichern (damit es beim > > nächsten Update nicht überschrieben wird) und anpassen > > - Bisherigen Job so anpassen, dass am Ende ein Kommando > ausgeführt > > wird (UnlockTickets.pl starten) > > > > Ist das ok oder habe ich noch nen Denkfehler drin? > > You're on GO. ;-) > Thanks a lot! =)

1 0

RE: [otrs-de] GenericAgent -> escalation
by Lars Monsees 09 Jan '04

09 Jan '04

(snip) > > > > > > der GenericAgent sieht nur die StateTypes, die in > > > > > > $Self->{ViewableStateType} = ... > > > > > > festgelegt sind. Ebenso nur die Locks, die mit > > > > > > $Self->{ViewableLocks} = ... > > > > > > bestimmt sind. > > > > Haben die Einstellungen noch an anderer Stelle Bedeutung, als nur > > beim GenericAgent? > > Der Name sieht für mich so allgemein aus und ich will verhindern, > > dass Nebenwirkungen auftreten. > > Oh ja! Probier's mal einfach aus... Bessere Lösung: Keine gelockten > Tickets bearbeiten. Keine Tickets locken, die verschoben > werden sollen. > Mit bin/UnlockTickets.pl arbeiten. > ah - I see Mal eben zu dem Szenario, weshalb ich diese Funktionalität benötige: Ein Agent hat mehrere Tickets gesperrt und diese ggf. auch bereits bearbeitet (aber noch nicht gelöst). Wenn diese nun ein bestimmtes Alter erreicht haben, sollen sie dem Agent entzogen werden (unlock - er soll aber weiterhin Besitzer bleiben, damit man sieht, wer vorher "dran" war) und der Queue Escalation zugeordnet werden. Somit soll verhindert werden, dass manche Support-Fälle einfach liegen bleiben nach dem Motto "wird sich mit der Zeit schon von alleine lösen". Habe mir bin/UnlockTickets.pl angeschaut. Nachteil ist für unser Szenario, dass Tickets nur berücksichtigt werden, wenn sie beantwortet sind und dass der Besitzer auf root geändert wird (*überleg* wobei man das ja über die Historie sehen kann). Das könnte ich natürlich leicht ändern, würde aber beim nächsten Update überschrieben werden. *überleg* Sollte ja aber gehen, wenn es unter einem neuen Namen abspeichere. Man kann mit dem CMD-Befehl auch mit einem Job Programme starten (wie dann das Skript zum Unlocken) - allerdings anscheinend nur _nachdem_ der Job die Tickets angepasst hat. *überleg* Das würde bedeuten, dass er im ersten Durchlauf keine Tickets findet, durch den Job UnlockTickets.pl startet und deshalb beim nächsten Aufruf die Tickets findet, oder? Lösung: - UnlockTickets.pl unter neuem Namen abspeichern (damit es beim nächsten Update nicht überschrieben wird) und anpassen - Bisherigen Job so anpassen, dass am Ende ein Kommando ausgeführt wird (UnlockTickets.pl starten) Ist das ok oder habe ich noch nen Denkfehler drin? Gruß, Lars

2 1