Hallo Leute,
Vielen Dank für das umfassende positive Feadback auf die erste Beschreibung.
Deshalb möchte ich mit diesem Post meine Anpassungen des Datums-Formates im vTiger für die Version 5.30 aktuallisieren.
Da das Team hinter vTiger in dieser Version größere Anpassungen in diesem Bereich gemacht haben, sind die Änderungen leider komplett anders. Allerdings deutlich übersichtlicher gewurden.
Da ich finde, dass sich der Ablauf bewährt hat, hier der übliche Ablauf der Änderungen:
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 : parse_calendardate(…) [Line ~221]
In if-Anweisung integrieren, bzw. einfach dahinter schreiben:
elseif($current_user->date_format == 'dd.mm.yyyy')
{
$dt_popup_fmt = "%d-%m-%Y";
}
/include/fields/DateTimeField.php
Funktion : __convertToDBFormat(…) [Line ~95]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
elseif ($format == 'dd.mm.yyyy') {
if(strpos($date, "-") !== false) {
list($d, $m, $y) = explode('-', $date);
} else {
list($d, $m, $y) = explode('.', $date);
}
}
An dieser Stelle wird leider ab und zu ein Format dd-mm-yyyy und die Einstellung des Users dd.mm.yyyy übergeben. Deshalb nochmal der Check.
Funktion: __convertToUserFormat((…) [Line ~157]
folgendes an passender Stelle einfügen: (If Abfragen sind gut erkennbar)
elseif ($format == 'dd.mm.yyyy') {
$date[0] = $d . '.' . $m . '.' . $y;
}
Funktion: convertToUserFormat(…) [Line ~139]
An dieser Stelle wird das Standard-Format des Vtigers auf dd.mm.yyyy gesetzt. Diese Einstellung ist besonders für die Extension PDFMaker relevant, da diese für Datumsausgaben in PDF’s aus einem Workflow genutzt wird.
Suchen:
if(empty($format)) {
$format = 'dd-mm-yyyy';
}
ersetzen:
if(empty($format)) {
$format = 'dd.mm.yyyy';
}
Funktion: convertToDBFormat(…) [Line ~139]
Suchen:
if(empty($format)) {
$format = 'dd-mm-yyyy';
}
ersetzen:
if(empty($format)) {
$format = 'dd.mm.yyyy';
}
include/js/general.js
Funktion: patternValidate(..)
Diese Position überprüft eingegebene Datumsangaben und muss ebenfalls um dd.mm.yyyy erweitert werden.
Folgendes suchen:
case "mm-dd-yyyy" :
case "dd-mm-yyyy" :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
und folgendermaßen ergänzen:
case "mm-dd-yyyy" :
case "dd-mm-yyyy" :
<strong>case "dd.mm.yyyy" :</strong>
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
Funktion splitDateVal(…)
Folgendes suchen:
case "dd-mm-yyyy" :
dateelements[0]=dateval.substring(0,dateval.indexOf(datesep))
dateelements[1]=dateval.substring(dateval.indexOf(datesep)+1,dateval.lastIndexOf(datesep))
dateelements[2]=dateval.substr(dateval.lastIndexOf(datesep)+1,dateval.length)
daraus folgendes machen (case “dd.mm.yyyy” für “dd-mm-yyyy” einfügen)
case "dd-mm-yyyy" :
case "dd.mm.yyyy" :
dateelements[0]=dateval.substring(0,dateval.indexOf(datesep))
dateelements[1]=dateval.substring(dateval.indexOf(datesep)+1,dateval.lastIndexOf(datesep))
dateelements[2]=dateval.substr(dateval.lastIndexOf(datesep)+1,dateval.length)
Funktion: re_patternValidate(…) [~LIne 4262]
Suchen:
case "dd-mm-yyyy" :
var re = /^\d{1,2}(-)\d{1,2}\1\d{4}$/
Daraus folgendes machen:
case "dd-mm-yyyy" :
case "dd.mm.yyyy" :
var re = /^\d{1,2}(\-|\/|\.)\d{1,2}\1\d{4}$/
include/ComboStrings.php
Um Line 304 steht die Zuweisung
'date_format_dom' => Array('dd-mm-yyyy'=>'dd-mm-yyyy',
'mm-dd-yyyy'=>'mm-dd-yyyy',
'yyyy-mm-dd'=>'yyyy-mm-dd'
),
Daraus folgendes machen:
'date_format_dom' => Array('dd-mm-yyyy'=>'dd-mm-yyyy',
'dd.mm.yyyy'=>'dd.mm.yyyy',
'mm-dd-yyyy'=>'mm-dd-yyyy',
'yyyy-mm-dd'=>'yyyy-mm-dd'
),
Bitte zuletzt noch das Datumsformat rechts oben unter “Meine Einstellungen” aktuallisieren, damit Ihr auch eine Änderung sehen könnt.
Ein Archiv mit allen bereits angepassten Files habe ich [Download herausgenommen] zum Download hochgeladen. Dabei bitte beachten, dass die Änderungen in ein Neues 5.30 gemacht wurden und alle Modifikationen überschreiben.
Andernfalls hier eine [Download herausgenommen] um das ganze automatisch einzutragen.
In beiden Fällen muss die Datenbankänderung aus dem ersten Schritt trotzdem durchgeführt werden!
Die anderen Updates für 5.30 kommen heute im Laufe des Tages online.
Bis dahin!
Bye
UPDATE
Entweder durch einen Bug im vTiger oder eine ungünstige Programmierung musste ich eine Stelle aktuallisieren.
Und ist die Funktion __convertToDBFormat in der DateTimeField.php von mir etwas erweitert wurden.
Deshalb habe ich auch nochmal die PATCH-Datei und das Archiv herausgenommen.
Recent Comments