Moritz Bunkus [Wed, 27 Apr 2016 12:45:46 +0000 (14:45 +0200)]
Request handling: bei zu hohem Speicherverbrauch erst flushen, dann beenden
Wenn sich das Script sofort beendet, dann werden Daten nicht an den
Webserverprozess geschickt und der wiederum schickt eine unschönen
Internal Server Error an den Client.
Daher zuerst den Request vollständig an den Server schicken und damit
den laufenden Request abschließen, bevor sich der Prozess beendet.
Die Perioden beginnen nicht mehr immer nur am 1. des Monats, sondern an
dem Tag, der über das Vertragsstartdatum angegeben ist. Daher müssen
auch die Variablen <%period_start_date%> und <%period_end_date%> anhand
des Vertragsstartdatums gesetzt und dürfen nicht auf den Monatsbeginn
beschnitten werden.
Sven Schöling [Thu, 21 Apr 2016 11:10:28 +0000 (13:10 +0200)]
Keine Default Exporte mehr in den main:: space
Ich hoffe ich habe alle erwischt. Dieser Commit, macht folgendes:
Exports in den main:: space passieren immer, wenn ein bin/mozilla/
script ein Modul einbindet, das @EXPORT setzt.
Laut meiner ack/grep Magie sind das SL::MoreCommon und SL::Helper::Flash
gewesen.
In beiden Fällen waren das importe, wo die eigentlichen Funktionen
vorher im main:: space gelegen haben und dann nachträglich in ein Modul
verschoben wurden.
Ich habe also:
1. Im script selber die Exportliste exakt auf die Funktionen gesetzt die
das script selber benutzt, gefunden mit dem oneliner:
Das waren in Flash: flash und in MoreCommon: save_form und restore_form.
2. Für den Fall, dass andere scripte im main:: Space diese Funktionen
benutzen alle anderen bin/mozilla Scripte nach diesen Funktionen
durchsucht, und für den Fall dass sie _nicht_ selber ein require
b/m/common.pl machen die entsprechenden imports hinzugefügt.
Nein, das war kein Fix für http://trac.kivitendo.de/ticket/2232
Implementiert wurde (imho):
a) Wenn es eine gültige Einheit gibt
b) Dann nimm das erstbeste Einzelteil einer Erzeugnis-Ware
c) und konvertiere die ausgewählte Einheit des Erzeugnis in die Einheit
der erstbesten Erzeugnis-Ware.
Jan Büren [Tue, 19 Apr 2016 13:10:52 +0000 (15:10 +0200)]
Erzeugnis fertigen verbessert
Transfertyp assembled hinzugefügt
Bei gefertigten Erzeugnissen sowie bei verbrauchten Waren
das tagesaktuelle Datum gesetzt (vorher wurde gar keins gesetzt).
Moritz Bunkus [Mon, 18 Apr 2016 13:19:37 +0000 (15:19 +0200)]
SL::DB::Printer: »Dokument an Drucker schicken« zentralisiert
Die neue Funktion print_document übernimmt das Spawnen des externen
Prozesses und schickt das Dokument an den Drucker. Das Dokument kann
entweder direkt als Inhalt oder als zu sendender Dateiname übergeben
werden.
Die gelieferte Menge pro Position wird über die Recordlinks der Items
zwischen Auftrag und Lieferschein(en) ermittelt.
So werden auch gleiche Artikel auf unterschiedlichen Positionen getrennt behandelt.
Ebenso ob ein Auftrag 'delivered' ist, d.h. ob alle Mengen vollständig in Lieferscheinen erfasst sind.
Für nachträglich hinzugefügte Lieferscheine oder Lieferscheine ohne Item-Recodlinks wird ein
Fallback-Verfahren durchgeführt, das beginnend von der ersten Auftragsposition
versucht die Artikel in den Lieferscheinen zuzuordnen.
Sven Schöling [Fri, 15 Apr 2016 17:18:58 +0000 (19:18 +0200)]
Menu: Fehlerchecks beim yaml einlesen
2 häufige Fehler abfangen:
- wenn ids in einer datei doppelt vorkommen (passiert beim editieren)
- wenn YAML selber Fehler wirft gab es bisher ein HTTP 500
Moritz Bunkus [Wed, 6 Apr 2016 14:45:50 +0000 (16:45 +0200)]
SL::Controller->send_file: trueish zurückgeben
send_file meldet Fehler (z.B. »kann Datei nicht öffnen«) durch
croak(). Im Erfolgsfall sollte die Funktion aber regulär einen wahren
Wert zurückgeben, um ordentlich in eval{} benutzt werden zu können.
Individuelle Lieferadressen werden nur von shipto.trans_id zu ar.id
verlinkt, nicht aber in ar.shipto_id. Die Implementation ist analog zu
SL::DB::DeliveryOrder->new_from.
Moritz Bunkus [Wed, 6 Apr 2016 11:59:31 +0000 (13:59 +0200)]
DeliveryOrder->new_from: kein $custom_shipto-Objekt zurückgeben
Falls das Quellobjekt eine individuelle Lieferadresse besaß, wurden bei
new_from() zwei Objekte zurückgegeben: das neue Lieferscheinobjekt und
ein Clone der individuellen Lieferadresse. Diese waren nicht verknüpft.
Der Aufrufer musste daher zuerst das Lieferscheinobjekt speichern,
dessen ID beim gecloneten Lieferadressenobjekt hinterlegen und das
anschließend speichern.
Dies ist umständlich und fehlerträchtig. So hat z.B. der einzige
bisherige Nutzer dieses Interfaces,
SL::DB::Order->convert_to_delivery_order, das bereits falsch gemacht und
vergessen, beim Lieferadressenobjekt die ID des neuen
Lieferscheinobjektes einzutragen. Somit wurden Lieferadressen erzeugt,
die keinerlei Verknüpfung hatten.
Das geänderte Interface hinterlegt das Objekt für die individuelle
Lieferadresse schlicht in $new_delivery_order->custom_shipto. Dort wird
das Objekt gespeichert, wenn der Lieferschein selber gespeichert wird.
PDF::Table - fehlerhafte Headerbearbeitung ab Seite 2
ab Seite 2 werden die benötigten Weiten der Spalten um die Zahl der Headerzeilen
nach hinten verschoben. Dann kommt es zu fehlenden Zeilenumbrüchen in manchen Zellen
Da Pushen von leerem Array führt zu diesem Fehler, d.h. es wird doppelt gepushed.
Dieser Fehler war schon in der alten PDF::Table
Moritz Bunkus [Mon, 4 Apr 2016 15:10:31 +0000 (17:10 +0200)]
JS: einige Scope-Fehler gefixt (von jshint)
Variablengültigheit hängt nicht von {} ab, sondern gelten immer für die
ganze Funktion. Daher ergibt mehrfachess »var xyz« innerhalb einer
Funktion keinen Sinn.
Moritz Bunkus [Fri, 1 Apr 2016 15:12:52 +0000 (17:12 +0200)]
ReportGenerator: Unterstützung für raw_header_data-Attribut in Spaltendefinitionen
Zuerst wurde dieses Attribut in Anlehnung an das Attribut bei den
Positionszeilen "raw_data" genannt. Leider kollidiert "raw_data" mit der
Benutzung des ReportGenerators aus dem Controller-Helfer-Modul
SL::Controller::ReportGenerator. Dieser verwendet "raw_data" in den
Spaltendefinitionen bereits für Defaults für die Erzeugung der
Positionszeilen.
Daher nun die Umbenennung des neuen Attributes nach "raw_header_data".