Kundennummer nachträglich (für alle Tickets) ändern
Hallo, ist es möglich, die Kundennummer nachträglich zu ändern? Es sollten die Einträge überall, also die der Personen und die der Tickets geändert werden. Ich denke daran dass wenn man die Kundennummer einer Person über die Web-GUI ändert das nicht die Kundennummerzuordnung der Tickets ändert. Man muss das Ticket danach wieder mit dem veränderten Kundeneintrag verknüpfen. Da die Änderung aber nun einige tausend Tickets betrifft muss ein Automatismus her. Ist das oben beschriebene möglich? Besten Dank und Grüße Sven Ehret Informations-Technologie Dienstleistungen COMDOK GmbH Eifelstraße 14 53757 Sankt Augustin Germany Tel.: +49 (0)2241.3 49 - 178 Fax: +49 (0)2241.3 49 - 111 mailto:ehret@comdok.de Geschäftsführer: Hans-Dieter Rapsilber Amtsgericht: Siegburg HRB: 2056 http://www.comdok.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Sven,
Es sollten die Einträge überall, also die der Personen und die der Tickets geändert werden. Ich denke daran dass wenn man die Kundennummer einer Person über die Web-GUI ändert das nicht die Kundennummerzuordnung der Tickets ändert. Man muss das Ticket danach wieder mit dem veränderten Kundeneintrag verknüpfen.
Da die Änderung aber nun einige tausend Tickets betrifft muss ein Automatismus her. Ist das oben beschriebene möglich?
nach derzeitigem Stand, ist dies nur mittels SQL-Anweisung z.B. via der SQL-Box im Adminbereich moeglich. viele Gruesse, Torsten Thau - -- Torsten Thau, Dipl. Inform. c.a.p.e. IT GmbH - Annaberger Str. 240 - D-09125 Chemnitz phone: +49 371 5347 623 cell: +49 176 66 680 680 personal pgp-key: 0x93E0A174 company pgp-key: 0x292F987D fax: +49 371 5347 625 http://www.cape-it.de AG Chemnitz - HRB 23192 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkuiWjQACgkQvXo8m5PgoXTz5gCeJv0Bc0kn90NObPPjX8hl3szf i2IAn3HxsXR3XVwqxt7bYlMy36uX4JW9 =VRfM -----END PGP SIGNATURE-----
On 18.03.2010, at 17:52, Torsten Thau wrote:
Es sollten die Einträge überall, also die der Personen und die der Tickets geändert werden. Ich denke daran dass wenn man die Kundennummer einer Person über die Web-GUI ändert das nicht die Kundennummerzuordnung der Tickets ändert. Man muss das Ticket danach wieder mit dem veränderten Kundeneintrag verknüpfen.
Da die Änderung aber nun einige tausend Tickets betrifft muss ein Automatismus her. Ist das oben beschriebene möglich?
nach derzeitigem Stand, ist dies nur mittels SQL-Anweisung z.B. via der SQL-Box im Adminbereich moeglich.
Ich habe hier eine zusätzliche Anmerkung. Das setzen der neuen Kundennummerzuordnung (hier in diesen Fall bei tausend Tickets) sollte man über den GenericAgent im Admin-Interface machen. 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. :) Von Änderungen direkten per SQL-Änderungen würde ich generell nicht machen (lieber über die API oder SOAP). :) Für Profis zumindest nicht in den Ticket-Tabellen (ticket, ticket_history, article, article_attachment), wegen der Revisionssicherheit. Liebe Grüße, -Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo,
Es sollten die Einträge überall, also die der Personen und die der Tickets geändert werden. Ich denke daran dass wenn man die Kundennummer einer Person über die Web-GUI ändert das nicht die Kundennummerzuordnung der Tickets ändert. Man muss das Ticket danach wieder mit dem veränderten Kundeneintrag verknüpfen.
Da die Änderung aber nun einige tausend Tickets betrifft muss ein Automatismus her. Ist das oben beschriebene möglich?
nach derzeitigem Stand, ist dies nur mittels SQL-Anweisung z.B. via der SQL-Box im Adminbereich moeglich.
Ich habe hier eine zusätzliche Anmerkung. Das setzen der neuen Kundennummerzuordnung (hier in diesen Fall bei tausend Tickets) sollte man über den GenericAgent im Admin-Interface machen.
...das ist korrekt. Natuerlich muesste man das fuer jeden Kundennutzer tun dessen Kundennummer sich aendert. Was bei vielen Aenderungen ueber den GUI-GenericAgent eine ziemliche Klickerei werden koennte. Ideal waeren hier die schon vorgeschlagenen CustomerEvents analog zu den Ticket- oder CI-Events bzw. einfach eine entsprechende Anpassung im Code. In jedem Fall muss die Aktualisierung der bestehenden Tickets hinsichtlich der KundenID aber konfigurier-/waehlbar sein.
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? 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) iEYEARECAAYFAkujVpgACgkQvXo8m5PgoXRJOQCfQpxLyzMRNkDC6YEntPwsl2Kb BUkAn03epnQ8gRiUq1kkn4NodsFytYt/ =5U91 -----END PGP SIGNATURE-----
Hi Torsten, On 19.03.2010, at 11:49, Torsten Thau wrote:
Es sollten die Einträge überall, also die der Personen und die der Tickets geändert werden. Ich denke daran dass wenn man die Kundennummer einer Person über die Web-GUI ändert das nicht die Kundennummerzuordnung der Tickets ändert. Man muss das Ticket danach wieder mit dem veränderten Kundeneintrag verknüpfen.
Da die Änderung aber nun einige tausend Tickets betrifft muss ein Automatismus her. Ist das oben beschriebene möglich?
nach derzeitigem Stand, ist dies nur mittels SQL-Anweisung z.B. via der SQL-Box im Adminbereich moeglich.
Ich habe hier eine zusätzliche Anmerkung. Das setzen der neuen Kundennummerzuordnung (hier in diesen Fall bei tausend Tickets) sollte man über den GenericAgent im Admin-Interface machen.
...das ist korrekt. Natuerlich muesste man das fuer jeden Kundennutzer tun dessen Kundennummer sich aendert. Was bei vielen Aenderungen ueber den GUI-GenericAgent eine ziemliche Klickerei werden koennte.
Ideal waeren hier die schon vorgeschlagenen CustomerEvents analog zu den Ticket- oder CI-Events bzw. einfach eine entsprechende Anpassung im Code. In jedem Fall muss die Aktualisierung der bestehenden Tickets hinsichtlich der KundenID aber konfigurier-/waehlbar sein.
Jo. Bzw. Ich sehe auch den Use-Case, dass man die Kunden ändern können müsste, ohne die Ticket-Zurodnung zu ändern (bzw. ich meine beide Möglichkeiten). D. h. wenn man in der GUI gefragt werden würde, ob man die Zuordnung auch gleich mit ändern wollen würde fände ich auch sehr schick. :) Ist im GUI Konzept für OTRS 3 mit drin (ich denke wir sollten bald die neue GUI offiziell vorstellen, damit es transparenter ist). :)
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. :) Liebe Grüße, -Martin
-----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-----
participants (3)
-
Martin Edenhofer -
sven.ehret＠comdok.de -
Torsten Thau