G. Richardson [Wed, 15 Jul 2015 10:24:29 +0000 (12:24 +0200)]
Projektliste in Detailsanzeige bei Angeboten, Aufträgen und VK-Rechnungen füllen (v2)
oe und is speichern die Projekt-Dropdowns, die im jeweiligen form_header
zusammengebaut werden, in $TMPL_VAR{ALL_PROJECTS}.
Das Projekt-Dropdown in io.pl für die Detailsanzeige (zweite
Positionszeile) greift hingegen für alle Belege auf
$form->{ALL_PROJECTS} zu, daher werden die Elemente nochmal gesondert in
$form gespeichert.
Moritz Bunkus [Fri, 3 Jul 2015 08:23:14 +0000 (10:23 +0200)]
GetModels: Disablen von Plugins auch für undef
Die Dokumentation sagt Folgendes zum Deaktivieren von Plugins:
> Configuration for plugins. If the option for any plugin is omitted,
> it defaults to enabled and is configured by default. Giving a
> falsish value as first argument will disable the plugin.
Das bisherige Verhalten war aber, dass bei Übergabe von
undef (z.B. »paginated => undef«) die Standardeinstellungen gegriffen
haben.
Aufträge sollten nicht an die Lieferadresse, sondern an die Stammdaten-Adresse
gehen. Zudem sind seit commit b6213d3539ccd179cd1f21b9afc54b8de8970774
"Einkauf/Verkauf: Lieferadressenfelder nie aus Stammdaten vorbelegen" die sipto-
Felder leer, wenn keine Lieferadresse angegeben ist.
jQuery kann aus HTML-Strings DOM-Objekte bauen:
$("<p>stuff</p>"). Beginnt der HTML-String mit Leerzeichen, so croakt
jQuery daran. Daher bei den betroffenen Funktionen, die immer auf einem
so gebauten DOM-Objekt hantieren, das Ziel-Argument um führende
Leerzeichen bereinigen.
G. Richardson [Wed, 17 Jun 2015 11:13:09 +0000 (13:13 +0200)]
Banktransactions Import - bessere Fehlermeldung wenn BLZ nicht stimmt
Beim Import wird sowohl Kontonummer oder IBAN als auch die BLZ geprüft.
Für den Fall, daß ein Konto anhand der importierten Kontonummer gefunden
wurde, die importierte BLZ aber nicht mit der dazu gespeicherten BLZ
übereinstimmt, gibt es nun eine aussagekräftigere Fehlermeldung.
Wahrscheinlich ist in diesem Fall die BLZ in den Bankkonteneinstellungen
falsch und muß dort aktualisiert werden.
Zumindest für den Fall, daß die IBAN übergeben wird, könnte man auf die
BLZ Prüfung wahrscheinlich auch verzichten.
G. Richardson [Fri, 12 Jun 2015 12:49:42 +0000 (14:49 +0200)]
Rechte für Bankbewegungen in Bankerweiterung setzen
Als sinnvollen Default erhalten beim Upgrade Gruppen, die schon das
Recht für "Zahlungseingang, Zahlungsausgang, Kontenabgleich" (cash)
besitzen, auch alle Rechte für die Bankerweiterung, also die Arbeit mit
den importierten Bankbewegungen.
Moritz Bunkus [Wed, 3 Jun 2015 12:35:23 +0000 (14:35 +0200)]
SL::DB::Helper::TransNumberGenerator: Belegnummern einmal direkt auslesen
Es werden alle vorhandenen Belegnummern benötigt. Diese wurden bisher so
ausgelesen, dass die Belege vom Rose-Manager via ->get_all komplett
geladen wurden und dann jeweils die Belegnummernspalte davon genommen
wurde. Das ist sehr langsam, vor allem da es potenziell sogar gleich ein
zweites Mal gemacht wurde.
Die Umstellung hier nutzt dafür ein direktes SQL-Query und umgeht Rose
dafür. Außerdem werden die nur einmal ausgelesen.
Moritz Bunkus [Wed, 3 Jun 2015 10:46:00 +0000 (12:46 +0200)]
SL::DB::Helper::TransNumberGenerator: Tabellen und Zeilen locken
Die Tabelle, aus der die Liste der bereits benutzten Belegnummern
ausgelesen wird, muss exklusiv gelockt werden, um zu verhindern, dass
danach zwischen dem Auslesen und der Vergabe der neuen Belegnummer eine
andere DB-Verbindung dasselbe macht und dieselbe Nummer verwendet.
Dieses Locking muss daher vor dem Auslesen der Daten geschehen.
Weiterhin müssen die Zeilen in den Nummernkreistabellen (defaults
bzw. business) gelockt werden. Hier reicht aber das Locking der
entsprechenden Zeile.
Beide Locks müssen analog zu SL::TransNumber gehandhabt werden, um einen
potenziellen Deadlock zu vermeiden, sprich zuerst die Belegtabelle,
danach die Zeile in der Nummernkreistabelle.
Moritz Bunkus [Wed, 3 Jun 2015 09:33:47 +0000 (11:33 +0200)]
SL::TransNumber: Belegtabelle vor Auslesen locken
Die Tabelle, aus der die Liste der bereits benutzten Belegnummern
ausgelesen wird, muss exklusiv gelockt werden, um zu verhindern, dass
danach zwischen dem Auslesen und der Vergabe der neuen Belegnummer eine
andere DB-Verbindung dasselbe macht und dieselbe Nummer verwendet.
Dieses Locking muss daher vor dem Auslesen der Daten geschehen.
Moritz Bunkus [Wed, 3 Jun 2015 09:15:56 +0000 (11:15 +0200)]
Task-Server: vor Schlafen aufräumen
Dabei werden unter Anderem potenziell noch laufende Transaktionen
beendet und zumindest das Standard-DBH (nicht das von Rose)
geschlossen. Dadurch sollten alle Locks, die durch die Jobs
evtl. entstanden sind, wieder aufgelöst worden sein.
Bernd Bleßmann [Mon, 1 Jun 2015 18:53:10 +0000 (20:53 +0200)]
HTML::Util: "nbsp" als HTML-Entity durch " " (space) ersetzen.
"nbsp" wird hier zu space, obwohl U+00A0 (non-breaking space) richtig wäre.
non-breaking space kann allerdings zu schwer zu findenden Fehlern zum Beispiel
beim CSV-Export führen, wenn ein Benutzer dieses nicht sichtbare Zeichen dann
per cut-and-paste irgendwo einfügt.
Sven Schöling [Mon, 1 Jun 2015 14:07:32 +0000 (16:07 +0200)]
ClientJS: Values nicht trimmen
Wenn numerische Werte (also IVs und NVs) per Regex getrimmt werden,
wird dabei das POK Flag gesetzt, das anzeigt, dass der Scalar auch ein
valider String ist.
JSON kann dann nicht mehr unterscheiden welcher Typ der Scalar ist, und
nimmt String. Das führt aber dazu, dass _alle_ Zahlen als Strings
encodiert werden.
Auch das wäre prinzipiell kein Problem, ausser dass Javascript keine
separaten Operatoren für Strings und Zahlen hat.
json.val1 + json.val2
wird also immer als concat aufgefasst und nicht als Addition, und
json.val ? true : false
ist immer true, weil "0" und "1" beide true in Javascript sind.
Bernd Bleßmann [Wed, 27 May 2015 12:56:03 +0000 (14:56 +0200)]
Ausdruck Erzeugnisse mit Stückliste und Lieferantenartikelnummer repariert.
Betraf wohl auch andere Felder zu Artikeln, die vor der Aufbereitung des
TEMPLATE_ARRAYS aus der DB gelesen wurden. Diese werden jetzt richtig in
TEMPLATE_ARRAYS einsortiert.
Um auch die Einträge für Erzeugnis-Teile und Warengruppen (beim Gruppieren
der Waren) in den Druckvorlagen unterscheiden zu können, gibt es ein Feld
'entry_type', dass die Werte 'normal', 'partsgroup', 'assembly-item' und
'assembly-item-partsgroup' annehmen kann.
Bernd Bleßmann [Sun, 24 May 2015 10:04:10 +0000 (12:04 +0200)]
Listenpreis in Belegen u. Ausdruck richtig formatieren und nicht mehr parsen.
listprice wird in den Belegen nur angezeigt. Man kann ihn nicht eingeben und
auch nicht speichern. Deshalb wird er jetzt nur zur Ausgabe formatiert
(io.pl:display_row, OE.pm:order_details, IS.pm:invoice_details), aber nicht
formatiert gespeichert.
io.pl:display_row schreibt ihn auch unformatiert als hidden in die Form.
Das war wohl so gedacht, aber nicht konsequent eingehalten und auch von mir an
einigen Stellen "verschlimmbessert" worden.
Evtl. sollte der listprice gar nicht als hidden mitgeschliffen werden, sondern
immer aus der DB gelesen werden.
projects / mfinanz.git / log