Disclaimer: Auch wenn ich ziemlich gründlich getestet habe und überzeugt bin, dass alles klappt - ein Restrisiko ist keinesfalls ausgeschlossen und ich übernehme keine wie auch immer geartete Verantwortung für irgendwelche Nebeneffekte bei Installation des hier angebotenen Moduls!
Das Modul berücksichtigt in dieser Version nur ein CustomerBackend. Bei mehreren Customer Backends müssten zumindest die Feldtypen übereinstimmen.
So. Ein neuer Wurf. Die Ticket.pm ist nun auch integriert, die Geschwindigkeitssteigerung insgesamt wirklich beeindruckend. Probiert einfach selbst aus.
Folgende Einstellungen müssen in der Config.pm vorgenommen werden (innerhalb der Definition der Kundendatenbank, also irgendwo innnerhalb von $Self->{CustomerUser} = { ... } )
Code: Select all
# SearchKeyType used in Ticket.pm ticket search and CustomerUser/DB.pm Searches
SearchKeyType => {
CustomerID => 'int', # UserCustomerID in Map
CustomerUserLogin => 'low', # UserLogin in Map
SearchForcedType => 'low' # Forces SearchType in manual CustomerSearch (e.g. Callticket or Emailticket)
# please make sure all CustomerUserSearchFields match the criteria!
},
Die Einstellungen betreffen zum einen die beiden zentralen Suchmerkmale (CustomerID und CustomerUserLogin) und legen deren Qualität fest (var, int, low, cas) und zum anderen wird ein Suchtyp für die manuelle Suche nach dem CustomerUser festgelegt (z.B. in der Suche im Ticket etc.). Die Config-Option der 0.0.2 hab ich wieder ausgebaut. Also bitte die 0.1.0 nicht einfach drüberinstallieren, sondern die 0.0.1 vorher deinstallieren.
Was var/int/low/cas bedeutet:
* 'var' ist die Grundeinstellung und heißt: Suchbegriff und DB Inhalt werden gelowert - hoff bloß nicht, dass das schnell geht
* 'int' wäre die optimale Variante, wenn OTRS damit umgehen könnte* weder SearchTerm noch DB Inhalt werden gelowert
* 'low' ist perfekt, wenn der DB Inhalt bereits gelowert vorliegt. Der SearchTerm wird sicherheitshalber noch gelowert - der Index benutzt.
* 'cas' nutzt auch den Index, allerdings wird vorrausgesetzt, dass der SearchTerm mit korrekter Groß-/Kleinschreibung aufwartet, da nichts gelowert wird.
Was im Einzelnen passiert:
Die
Ticket.pm wurde so modifiziert, dass die entscheidenden Merkmale jetzt separat abgetestet werden. Die Stelle verbirgt sich hinter # other ticket stuff, ca. Zeile 4150:
- Ticketnummern werden nie gelowert, Ticket-Titel dagegen immer
- Für CustomerID und CustomerUserIDs wird der SearchKeyType aus der Config.pm ermittelt und die richtigen LOWER Parameter für den SearchTerm und die DB gesetzt
- CustomerIDs/CustomerUserIDs ,die ein @ enthalten werden immer gelowert (nicht zugeordnete Tickets)
Die
CustomerUser/DB.pm arbeitet von Hause aus mit dem CustomerKey als Suchkriterium. Hier ist zumindest die Möglichkeit vorgesehen, dass der abgelegte Wert (das UserLogin) integer sein kann - was er selten sein dürfte**. Ich habe die Möglichkeiten um 'cas' und 'low' erweitert - definiert über den SearchKeyType in der Config.pm.
Der
SearchForcedType legt global fest, wie die manuelle Suche über die definierten CustomerSearchFields ausgeführt wird. Hier bin ich noch nicht ganz zufrieden, da u. U. unterschiedliche Feldtypen über einen Kamm geschoren werden. Bei unserem Setup funktioniert 'low' perfekt, da wir nach userLogin, email und userID suchen, die allesamt low in der Datenbank liegen. Zukünftige (bzw. Standard-geeignete) Varianten sollten hier noch differenzieren. Das könnte über die Deklaration in der Map geschehen.
Insgesamt bin ich mit dem bisherigen Ergebnis recht zufrieden. Ich denke, man könnte die Konfiguration noch 'automatisieren', indem man die Map sauber einliest und die Variante über den ForcedType kann man auch eleganter lösen. Vielleicht komm ich ja mal irgendwann dazu.
Lasst es Feedback regnen! Ich hab bereits ca. 4-5 Tage meiner Lebens- und Arbeitszeit in das Projekt gesetzt. Wäre also klasse, wenn ihr die 4-5 Minuten hättet, Anregungen bzw. Kritik und/oder eure Erfahrungen unterzubringen.
Gruß
Daniel
* Tatsächlich ist 'low' immer schneller, da bei INT die Anführungszeichen um den DB Teil weggelassen werden. Da die customer_id/customer_user_id jedoch VARCHAR deklariert sind, wird dann der Index nicht benutzt
** OTRS setzt vorraus, dass CustomerKey mit dem UserLogin übereinstimmt (was eine gewagte These ist...) und checkt ob das UserLogin integer ist. Wäre interessant, mal auszuprobieren, den CustomerKey auf einen nicht-Integer Wert zu setzen und das UserLogin Integer - dann funktioniert wahrscheinlich nix mehr so richtig... ein klarer Bug, der allerdings selten auftreten wird.