Sven Schöling [Tue, 8 Jan 2013 15:37:27 +0000 (16:37 +0100)]
Stillen Fehler bei cascade-save von one-to-many relations behoben.
Folgendes Phänomen:
table X table X_items
id X_id references X(id)
wird in Rose zu
SL::DB::X und SL::DB::XItems, wobei SL::DB::XItems::X eine automatische
relationship zu X bildet, und in den meisten Fällen SL::DB::X::items eine
manuelle Relationship in die Gegnrichtung.
Was nun passiert ist, war, dass ein save(cascade => 1) auf X die items nicht
mitegspeichert hat.
Das Problem war, dass unser Hooksystem nicht sichergestellt hat, dass die
überladene save Methode von SL::DB::Object immer das Ergebnis der eigentlichen
Speicherung zurückgeliefert.
Rose::DB::Object selber braucht diesen Rückgabewert nicht, und dokumentiert das
Verhalten auch nur informal. Die von den relations angelegten post-save Hooks
prüfen den aber, und schmeissen bei nichterfolg eine Exception.
Das nächste Problem ist jetzt, dass Rose::DB::Object intern die Fehler nicht
direkt wirft, sondern den letzten Fehler in $self->error speichert, und den
dann einfach wirft. Unser undef der überladenen save Methode wird als Fehler
erkannt, aber weil nie ein Fehler gesetzt wurde, wird effektiv "die undef"
aufgerufen.
Das landet dann als "Died at .../Rose/DB/Object/MakeMethods/Generic.pm line
3741." im eval error von Rose::DB::Object::save. Das gibt das Ganze weiter an
den Rose::DB::Object::Metadata::handle_error, der das wiederum an Carp::croak
weitergibt.
Carp packt das gnaze in eine weitere Lage "Died at" ein, und bubblet das ganze
weiter an unser Hooksystem, wo die Rose::DB::do_transaction den Fehler fängt,
und folgerictig ein rollback triggert.
Jetzt der Trick: Bei Rose ist Rose::DB::Object für die Eskalation zuständig.
Rose::DB::do_transaction beendet nur die Transaktion und sieht zu dass nichts
kaputtgeht, und gibt dann undef zurück. Die Exception ist damit im
Errorattribut der DB Connection versenkt.
Rose::DB::Object umgeht das gleiche Problem indem im Fehlerfall die Exception
gefangen wird, die Transaktion sauber beendet wird, und danach erst der
Metadata::handle_error den Fehler zur weiteren Eskalation bekommt.
Dieser Patch erweitert unser Hooksystem so, dass immer der Rückgabewert des
RDBO::save zurückgegeben wird, was dann den Fehler nicht mehr triggert.
Zusätzlich müssen später noch Exceptions im Hooksystem gefangen werden, und
auch da sauber die Transaktion beendet werden, bevor die gehandhabt werden.
Thomas Heck [Fri, 14 Dec 2012 15:20:09 +0000 (16:20 +0100)]
Bankkonten löschbar machen
Da Bankkonten nur von SEPA(und dort nur die Kontodaten kopiert werden) verwendet
werden, muss nicht geprüft werden, ob das Konto noch verwendet wird.
fixt #2085
In dem Abschnitt ar sollen die Erlöse laut ac.amount relativ zu den
Zahlungseingängen ausgewiesen werden. Dann kam eine Prüfung rein, ob der
Rechnungsbetrag vielleicht 0 ist, um eine 0 im Nenner zu verhindern.
Diese Prüfung greift aber sowohl bei Verkaufsrechnungen mit Betrag 0 als
auch fälschlicherweise bei Eingangsrechnungen mit Betrag x. Diese
Aufwände wurden dann mit 1 multipliziert und haben dann die Aufwände,
die später im ap-Teil berechnet wurden, negiert, weshalb die Ausgaben
alle 0 waren. Der Patch von Uwe Konrad macht also genau das Richtige,
und ich habe noch ein paar überflüssige Prüfungen auf 0 rausgenommen.
Damit sollte die Funktionalität wie von vor der 0-Prüfung
wiederhergestellt sein.
Ob dieses Verfahren dann noch richtig ist, wenn Bug 1793 angegangen
wird, muß man dann noch sehen.
Moritz Bunkus [Tue, 27 Nov 2012 08:08:04 +0000 (09:08 +0100)]
Reverting "Ersatz fuer kvitendo css - ist mit nosi abgesprochen - entspricht z.Z. lx-office-erp, mit anderer Farbgebung. - bekommt noch kleine Korrekturen"
- Es ist nur ein Workaround. Die richtige Lösung ist, die Stellen, die
die falschen/alten Pfade nutzen, entsprechend zu fixen. Mich würde
auch brennend interessieren, wo diese Stellen genau sind.
- Wenn ein Browser direkt aus dem Pfad .../css/ eine CSS-Datei lädt, so
werden alle relativen Pfadangaben in dieser Datei von .../css/ aus
interpretiert. Selbst wenn das ein symbolischer Link ist, was der
Browser ja nicht mitbekommt. Da die Dateien selber aber in einem
Unterverzeichnis von .../css/ liegen (und nicht in .../css/ selber),
gehen damit relative Pfadangaben kaputt. Diverse Stylesheets nutzen
auch relative Pfadangaben bereits.
Sven Donath [Thu, 22 Nov 2012 17:15:07 +0000 (18:15 +0100)]
CSS Edit Workaround
Unter System->Vorlagen->Stilvorlage wurde die passende Datei nicht geladen,
da sich die Pfade geändert haben.
Von einigen anderen Stellen werden ebenfalls noch die alten css/*.css - Dateien erwartet.
Daher vorerst die Symlinks.
Durch den Fix von Bug 1990 wurden die Dezimalstellen, die man für
die Genauigkeit der Rechnung angeben kann, beim VK-/EK-Betrag
missachtet. Jetzt wird wieder auf die angegebene Ahnzahl von Dezimalstellen
gerundet. Der Verkaufsbericht liefert dieselben Werte wie Verkauf-
Berichte-Rechnungen, wenn man auf 2 Dezimalstellen runden lässt.
Weiterhin wird nun auch die Marge auf die angegebene Anzahl von
Dezimalstellen gerundet anstatt immer auf 2.
projects / mfinanz.git / log