UPDATE: Änderungen für vTiger 5.30 befinden sich in einem extra Post.
Dies soll der erste Post einer Reihe von Artikeln sein, welche sich um Anpassungen des CRM-Systems vTiger drehen.
Da ich beruflich in den letzten Wochen sehr viel mit dieser Software zu tun hatte, wollte ich meine Erkenntnisse im Internet veröffentlichen um evtl. anderen Hilfesuchenden behilflich zu sein.
In diesem ersten Artikel geht es jetzt darum, wie ich das größte Problem beim Einsatz eines vTigers mit Kundenkontakt in Deutschland habe: Das Datumsformat.
Von Haus aus unterstützt das CRM leider nur die folgenden Formate:
- yyyy-mm-dd
- dd-mm-yyyy
- mm-dd-yyyy
Punkt 2 kommt dem deutschen Format „dd.mm.yyyy“ zwar schon sehr nahe, wirkt aber doch unprofessionell, da auf ausgehenden Rechnungen das Datum mit „10-02-2009“ angegeben ist.
„Kein Problem“, dachte ich mir und begann das System zu untersuchen … und verstand langsam, warum es nicht alzu viele Extensions zu dem System gibt. … Es ist einfach unheimlich komplex.
Lösung
Zu erst, habe ich in der Tabelle „vtiger_date_format“ eine Zeile mit folgendem Inhalt eingefügt:
date_formatid : 4
date_format : dd.mm.yyyy
sortorderid : 0
presence : 1
Die Spalte sortorderid kann natürlich angepasst werden, um die Formatauswahl umzusortieren. Bei mir war einzig das deutsche Format notwendig, weshalb es auch an erster Stelle erscheinen sollte, damit es als Standard gewählt wird.
Daraufhin fingen die Probleme an. Erst wurden zu importierten eMails (Die Anpassung fand während der Einrichtung des Systems statt) keine Sende-Daten mehr gespeichert, dann verschwanden Geburtsdaten und Rechnungsdaten.
Das Ergebnis war also wenig zufriedenstellend, sodass ich motiviert weitergesucht habe.
Daraufhin habe ich in folgenden Dateien noch Änderungen gemacht, damit das deutsche Datumsformat verfügbar ist. (Die Zeilenangaben richten sich jeweils an ein vTiger Version 5.21)
Ich versuche die Positionen aber zu beschreiben, sodass auch andere Version davon profitieren können.
include/utils/CommonUtils.php
Funktion : getNewDisplayDate(…) [Line ~1012]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif($dat_fmt == ‚dd.mm.yyyy‘)
{
$display_date = date(‚d-m-Y‘);
}
[/php]
Funktion: parse_calendardate(…) [Line ~221]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif($current_user->date_format == ‚dd.mm.yyyy‘)
{
$dt_popup_fmt = "%d.%m.%Y";
}
[/php]
Funktion: getDisplayDate(…) [Line ~945]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
[php]
elseif($dat_fmt == ‚dd.mm.yyyy‘)
{
$display_date = $d.‘.‘.$m.‘.‘.$y;
}
[/php]
include/utils/utils.php
Funktion: getDBInsertDateValue(…) [Line ~1541]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
Achtung! Der Bindestrich an dieser Stelle ist korrekt. Erklärung folgt darunter.
[php]
elseif($dat_fmt == ‚dd.mm.yyyy‘)
{
list($d,$m,$y) = explode(‚-‚, $value);
}
[/php]
Offenbar wird der Funktion getDBInsertDateValue(…) ab und zu ein Datumsformat übergeben, in welchem alle nichtnumerischen Zeichen durch den Bindestrich ersetzt werden. (Genauer: Bei der JavaScript-Inpage Edit-Funktion)
Deshalb habe ich in der Funktion getDBInsertDateValue(…) nach der Zuweisung von $dat_fmt [Line ???] folgende Zeile eingefügt:
[php]
$value = str_replace(".", "-", $value);
[/php]
Diese ersetzt alle Punkte durch Bindestriche, sodass dd.mm.yyyy im Grunde zu dd-mm-yyyy wird.
include/js/general.js
Funktion: patternValidate(..)
Hier wird offenbar nicht korrekt geprüft, ob das pattern überhaupt gesetzt wird, weshalb der Ajax-Edit nicht mehr korrekt abgeschickt werden kann. Deshalb folgende Stelle suchen:
[php]
if (type.toUpperCase()=="TIME") {//TIME validation
var re = /^\d{1,2}\:\d{1,2}$/
}
[/php]
und danach folgendes einfügen:
[php]
if(re == undefined)
return true;
[/php]
include/ComboStrings.php
Um Line 304 steht die Zuweisung
[php]
‚date_format_dom‘ => Array(‚dd-mm-yyyy’=>’dd-mm-yyyy‘,
‚mm-dd-yyyy’=>’mm-dd-yyyy‘,
‚yyyy-mm-dd’=>’yyyy-mm-dd‘
),
[/php]
An dieser Stelle muss folgende Zeile eingefügt werden. Bestenfalls vor der ‚mm-dd-yyyy‘ Zuweisung
[php]
‚dd.mm.yyyy‘ => ‚dd.mm.yyyy‘
[/php]
Ich verspreche nicht, dass durch die Änderung des Datumsformates später nicht noch weitere Probleme auftreten, werde diesen Post allerdings updaten und dahingehend aktuell halten, wenn sich solche Probleme in unserer, oder eurer, Umgebung abzeichnen sollten.
Leider wurde unser Format bei der Entwicklung vom vTiger komplett vergessen. Trotz dessen ist dieses KOSTENFREIE CMS problemlos auch in Deutschland einzusetzen und gerade weil es in der Basis keinen Euro kostet, schon Wert genutzt zu werden.
Ich habe noch einige Problemlösungen auf Lager und werde diese im Laufe der Tage noch posten.
Unter anderem:
- Rechnungen über Webservice mit einer Produktliste anlegen
- Schwierigkeiten mit dem Webservice und UTF-8
- Listen standardmäßig nach der ersten Spalte sortieren, statt der ID, damit jeder User die Sortierung ändern kann
Bis dahin!
Bye
UPDATE [19.07.2011]:
Da ich den Hinweis vergessen hatte:
Um die Änderungen zu aktivieren, müsst Ihr unter „Meine Einstellungen“, rechts oben, das neue Datumsformat „dd.mm.yyyy“ auswählen. Ansonsten nutzt Ihr weiter die fest integrierten Formate.
UPDATE2 [26.09.2011]:
Solltet Ihr ein komplett neues vTiger-System nutzen, könnt ihr auch folgendes Archiv nutzen, welches alle geänderten Dateien beinhaltet. Die Datenbankänderung in Schritt 1 müsstet Ihr aber trotzdem durchführen:
https://stefanwarnat.de/wp-content/uploads/2011/07/vtiger_files1.zip
