Eigenes Datenbankmodell für Kunden?

[dadudeness]

Moin zusammen,

wir möchten OTRS an einer Kundendatenbank einsetzen, jedoch stellt sich für mich gerade eine Grundfrage:
Wenn ich mir die OTRS-Datenbank customer_user der Grundinstallation anschaue, werden dort alle Felder gelistet, die beim Anlegen eines Kunden aus OTRS heraus abgefragt werden. Dass diese nicht ausreichen, bzw. die Anzahl der Felder i.d.R. im Einsatz erweitert werden muss, wird wohl in beinahe jeder Umgebung notwendig sein. Dies ist auch nicht das hauptproblem, da diese Änderungen ja im Abschnitt Kunden-Mapping des Admin-Handbuches beschrieben sind. Jedoch wundert es mich doch sehr, daß keinerlei Normalform eingehalten wird, da die Kundendaten alle in einer einzigen Tabelle gespeichert werden.

Meine Frage ist nun die: Ist es möglich, ein eigenes Datenbankmodell so in OTRS zu integrieren, dass auf diesem, welches Daten in verschiedenen Relationen speichert, gearbeitet wird, oder ist es eigentlich so "gedacht", daß die OTRS-Datenbank losgelöst von anderen Systemen betrieben wird, so daß ein regelmäßiger Datenabgleich stattfinden muss?
Ich gehe davon aus, dass es in der Tat "möglich" ist, jedoch würde eine tiefgreifende Anpassung des Systems, falls diese während der Entwicklung nicht vorgesehen war, evtl. dafür sorgen, dass diese nach jedem Updateschritt wiederholt werden müsste, was ich natürlich gern verhindern würde.

Würde mich freuen, wenn jemand mir etwas auf die Sprünge helfen könnte.

Grüße aus Hamburg
Fabian

[root]

Hallo,

da OTRS eine einzelne Tabelle benötigt bietet sich doch ein View an. So haben wir es auch mit unserem CRM gelöst (Oracle DB als Backend).
Dazu kann man dann ja auch die einzelnen Felder auf Readonly setzen um zu verhindern das diese in AdminCustomerUser geändert werden.
Allerdings hat unser CRM kein Feld für Passwörter, so das wir aus der View eine identische Tabelle via Trigger gebaut haben die als einzigen Unterschied
ein Passwortfeld enthält. Das ist dann auch das einzige Feld was man beschreiben darf.
Leider probiert OTRS auch die Readonly-Felder wieder zu schreiben, dafür habe ich bei uns einen kleinen Workaround gebaut, zu finden unter http://bugs.otrs.org/show_bug.cgi?id=5240

hth, Roy

[dadudeness]

Vielen Dank für die Antwort!

Zum Anzeigen ist eine View wirklich eine gute Lösung, jedoch bekomme ich noch ein paar Bauchschmerzen, wenn es darum gehen soll, Kunden anzulegen. Ich werde mich der Sache mal annehmen.

Gruß
Fabian

[root]

Vielen Dank für die Antwort!

Zum Anzeigen ist eine View wirklich eine gute Lösung, jedoch bekomme ich noch ein paar Bauchschmerzen, wenn es darum gehen soll, Kunden anzulegen. Ich werde mich der Sache mal annehmen.

Das Anlegen von Kunden gibt es dann halt nur in der OTRS-eigenen Datenquelle (Tabelle customer_user) bzw. im Ursprungssystem, so wird das bei uns gehandhabt.
Das würde auch gar nicht funktionieren, da wir Kunde aus insgesamt 6 Datenqellen holen (4 x AD/LDAP, 1 x PostgreSQL, 1 x Oracle) und keine Agent festlegen könnte wo der Kunde hingehört.
Hier gilt "Configuration by Convention"

Roy

[dadudeness]

Ursprünglich war es mal geplant, dass das OTRS eine Art Grundsystem darstellen sollte. Von dieser Idee scheint sich das Projekt mehr und mehr entfernen zu müssen.
Ich überlege im Moment für die Stammdaten-Pfelge und -Verwaltung ein Tool auf Basis des yii-Frameworks zu entwickeln und OTRS hauptsätzlich die Kernaufgbe zu überlassen, nämlich Tickets zu erstellen.

Schade, dass es kaum möglich ist, alles über ein Tool zu erledigen.

Fabian