Fehler #304
Datumsformat wechselt willkürlich auf Datenbank Format "YYYY-MM-DD"
0%
Beschreibung
The 'day' parameter ("2017") to DateTime::new did not pass the 'an integer which is a possible valid day of month' callback
at /usr/lib/x86_64-linux-gnu/perl5/5.22/DateTime.pm line 197.
DateTime::new(undef, "year", 2007, "month", 9, "day", 2017) called at SL/DB/Helper/Attr.pm line 88
SL::DB::Helper::Attr::__ANON__(SL::DB::Order=HASH(0xa3c4208), "2017-09-07 07:17:03.339028") called at bin/mozilla/io.pl line 1897
main::_make_record() called at bin/mozilla/io.pl line 242
main::display_row(2) called at bin/mozilla/oe.pl line 2082
Bin mir nicht sicher, ob es an der aktuellen unstable und/oder an Erweiterungen beim Kunden liegt.
Mal wird das Benutzerformat des Datums angezeigt und mal das Datenbank-Format.
Ferner springt die Darstellung innerhalb einer Benutzer-Session (der eine Beleg ist defekt, der nächste Bericht wieder i.O.)
Hat einer eine Idee zum Eingrenzen?
Watchdog auf myconfig oder sowas?
Historie
Von Jan Büren vor mehr als 6 Jahren aktualisiert
- Status wurde von Neu zu Abgewiesen geändert
Ok, es liegt an meiner Erweiterung in der SL/Auth.pm
Ich will hier benutzerdefinierte E-Mails im Mandant überlagern, a la:
--- a/SL/Auth.pm
+++ b/SL/Auth.pm
@@ -487,6 +487,9 @@ sub read_user {
$sth->finish();
+ my $user = SL::DB::Manager::Employee->find_by(login => $user_data{login});
+ $user_data{email} = $user->{custom_email} if ($user->{custom_email});
+ $user_data{signature} = $user->{custom_signature} if ($user->{custom_signature});
return %user_data;
}
Ich würde jetzt raten und vermuten, dass der Mandant für DB/Manager/Employee nicht zu Verfügung steht, aber bisher kam immer ein korrektes $user-Objekt zurück.
Ich hab die Überlagerung jetzt nach SL/User.pm gepackt.
Das tieferliegende Problem ist eher, dass es nur die mandantenweite E-Mail-Signatur gib. Für personalisierte E-Mail und E-Mail-Signatur geht das leider nicht.