-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Martin, Danke fuer die schnelle Antwort.
Das hat den Vorteil, dass die Änderung am Ticket protokolliert wird und die Revisionssicherheit von OTRS weiter unterstützt wird (alle Änderungen werden in der ticket_history protokolliert). Zudem stimmen Statistiken, welche später generiert werden noch. :)
Der erste Teil ist klar, beim zweiten haenge ich etwas: inwiefern hat eine (zugegebenermassen unsaubere) Aenderung der KundenID an Tickets via Direkt-SQL eine Auswirkung auf die Korrektheit der Statistiken?
Kein Problem. Es ist so, dass Aufgrund der Ticket-Historie auch Statistiken erstellt werden können.
Ein Beispiel ist: Gibt mir heute (19.03.2010) die Anzahl der Offenen Tickets zum 31.12.2009. Oder welche Kunden-ID hatte am 31.12.2009 wie viele offene Tickets.
Gerne auch mehr Infos. :)
Das mit Statistiken via ticket_history ist soweit klar. Ich frage nur weil in Tabelle ticket_history AFAIK derzeit keine Spalte customer_id oder customer_user_id enthalten ist. Man koennte also fuer das Reporting mit Bezug auf KundenID nur ueber den Kommentartext (Spalte name) gehen - was aber u.U. nicht sehr performant sein koennte. Sollte die beiden Spalten n.n, fuer OTRS >= 2.4.x geplant sein, wuerde ich das gleich als FR anmelden :-). CU, Torsten - -- Torsten Thau, Dipl. Inform. c.a.p.e. IT Labs GbR - Annaberger Str. 240 - D-09125 Chemnitz phone: +49 371 5347 623 cell: +49 176 66 680 680 personal pgp-key: 0x93E0A174 fax: +49 371 5347 625 http://www.cape-it.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkujcCUACgkQvXo8m5PgoXS4hgCfeH5tG271VmQGHNvN8FXJD/4H IYIAoIqITTgWb96S96qQ9XcLdxca083U =Bk/R -----END PGP SIGNATURE-----