Moritz Bunkus [Fri, 30 Aug 2019 12:53:43 +0000 (14:53 +0200)]
DB-Upgrades für Hintergrundjobs von Perl auf SQL umgestellt
Rose-Models dürfen in DB-Upgrade-Scripten nicht verwendet werden, weil
die Perl-Strukturdaten (MetaSetup) in dem Moment schon auf dem neuen
Stand, die Datenbankstrukturen aber auf dem alten Stand sind. Daher
schlagen bei Unterschieden (z.B. eine Spalte soll später noch angelegt
werden, sie existiert aber im neuen MetaSetup schon) halt sämliche
Operationen fehl.
Moritz Bunkus [Mon, 26 Aug 2019 09:36:36 +0000 (11:36 +0200)]
SelfTest: Geschwindigkeitssteigerung durch »NOT EXISTS« anstelle von »NOT IN«
Nicht ganz frische PostgreSQL-Versionen (mindestens bis 9.6 inklusive)
optimieren »NOT IN«-mit-Subquery nicht automatisch und müssen daher
für jede Zeile des äußeren Selects einen linearen Scan auf die
Subquery-Tabelle machen.
Deutlich effektiver ist das in diesem Fall äquivalente »NOT
EXISTS«-mit-Subquery.
Beispiel: Namen aller Kunden, für die noch keine Rechnung geschrieben
wurde. Falsch mit »NOT IN«:
SELECT name
FROM customer
WHERE id NOT IN (
SELECT customer_id
FROM ar
);
Besser und semantisch äquivalent:
SELECT name
FROM customer
WHERE NOT EXISTS (
SELECT customer_id
FROM ar
WHERE customer_id = customer.id
);
Geschwindigkeitssteigerung ist auch ein Euphemismus. Vor der Änderung
war der Selftest bei der LINET-Produktivdatenbank nicht in der Lage,
seine Tests innerhalb von drei Tagen auszuführen. Nach der Änderung
dauert der Selftest weniger als eine Minute.
Neure PostgreSQL-Versionen (z.B. v11) erkennen dieses Pattern
automatisch.
Moritz Bunkus [Mon, 29 Apr 2019 13:54:30 +0000 (15:54 +0200)]
Auth: Unterstützung für multiple Authentifizierungsbackends
Über den Parameter "module" kann man nun multiple Backends angeben,
die nacheinander versucht werden, bis ein Erfolg gemeldet wird oder
die Liste durchlaufen wurde.
Zusätzlich kann man LDAP-Module mehrfach angeben. Damit
unterschiedliche Konfigurationen für jede Modulinstanz benutzt werden
können, wurde die Syntax erweitert: für "LDAP:Config-Abschnitts-Name"
wird "[authentication/Config-Abschnitts-Name]" benutzt. Zwecks
Rückwärtskompatibilität sucht "LDAP" ohne Angabe eines Namens nach dem
bisher auch verwendeten Abschnitt "[authentication/ldap]".
Nützlich ist das Ganze z.B., um einen LDAP-Fallback-Server angeben zu
können, der benutzt wird, wenn der Hauptserver nicht erreichbar sein
sollte.
Moritz Bunkus [Mon, 29 Apr 2019 13:32:22 +0000 (15:32 +0200)]
Auth: mini_error gefixt
$::auth->mini_error wird potenziell zu einem Zeitpunkt aufgerufen, an
dem es die Instanzen von $::form und $::request noch nicht gibt. Da
hier wirklich nur die Bare-Bones-Ausgabe der Fehlermeldung benötigt
wird, machen wir für den Fall manuell ein CGI-Objekt auf.
Moritz Bunkus [Fri, 23 Aug 2019 09:17:39 +0000 (11:17 +0200)]
Task-Server auf unterschiedlichen Maschinen laufen lassen können
Jede Task-Server-Instanz und jeder Hintergrundjob haben nun ein neues
Attribute »node_id«. Darüber kann gesteuert werden, dass bestimmte
Jobs nur von einer bestimmten Instanz ausgeführt werden.
Die »node_id« eines neu angelegten Jobs ist standardmäßig leer. Das
bedeutet, dass ein Job von einer beliebigen Task-Server-Instanz
ausgeführt werden kann.
Die »node_id« eines Task-Servers ist standardmäßig der Hostname (siehe
ausgabe von »perl -MSys::Hostname -le 'print hostname()'«), kann aber
in der Konfigurationsdatei überschrieben werden (»[task_server]« →
»node_id«).
Zusätzlich gibt es den Konfigurationsparameter »[task_server]« →
»only_run_tasks_for_this_node«. Ist dieser Parameter gesetzt, so führt
der Task-Server nur diejenigen Jobs aus, deren »node_id«-Feld mit der
»node_id« der Task-Server-Instanz übereinstimmt. Andernfalls werden
auch diejenigen Jobs ausgeführt, deren »node_id«-Feld leer ist.
Achtung: es findet momentan keinerlei Locking statt. Das bedeutet,
dass es für jede Datenbank nur eine Task-Server-Instanz geben darf,
bei der »only_run_tasks_for_this_node« nicht gesetzt ist. Für
Load-Balancing eignet sich das also bisher noch nicht.
Für jedes Aufwandskonto der Positionen im Lieferantenauftrag wird eine
Zeile in der Kreditorenbuchung erstellt. Gebucht wird standardmäßig
auf des entsprechende Aufwandskonto. In der Mandantenkonfiguration
kann unter Standardkonten ein Konto ausgewählt werden, auf das dann
alle Zeilen gebucht werden.
Die Steuern werden übernommen, sofern diese für das ausgewählte
Aufwandskonto gültig sind. Ansonsten wird die Default-Steuer für das
Aufwandskonto gesetzt.
Der Quellauftrag wird geschlossen, wenn der Betrag aller
Kreditorenbuchungen, die aus Workflows aus dem Quellauftrag entstanden
sind, gleich dem Betrag des Quellauftrags ist.
G. Richardson [Sat, 10 Aug 2019 15:00:10 +0000 (17:00 +0200)]
Part Controller - neuer Tab mit Lagerinformationen
* Übersicht über alle Lagerbestände, wo der Artikel überall gelagert ist
(Derzeit gibt es im Template Variabeln um Zwischensummen und
Nachkommastellen zu kontrollieren)
* Mini-Journal mit den letzten 10 Lagertransaktionen des Artikels
Diese Daten werden nur bei Bedarf geladen, also wenn der Benutzer auf
den neuen Tab "Lagerbewegungen/-bestände" klickt.
Außerdem gibt es Links zu diversen Lageraktionen (Einlagern, Umlagern,
Entnahme), wo der Artikel dann schon vorausgewählt ist.
G. Richardson [Wed, 20 Feb 2019 11:30:16 +0000 (12:30 +0100)]
Aggregatfunktion comma entfernt und Templates angepasst
"comma" war eine alte benutzerdefinierte Aggregatfunktion, die benutzt
wurde, um mehrere aggregierte Werte aus einem GROUP BY in einen
kommaseparierten String umzuwandeln.
Mittlerweile würde man das einfach mit array_agg und array_to_string machen:
array_to_string(array_agg(startdate), ', ') as startdate
Im Template wurden die ',' dann durch '<br>' ersetzt. Stattdessen werden
die Werte im Query nun als array_agg ausgegeben, und im Template wird
eine Schleife über das Arrayref gebildet.
selectall_array_query durch selectcol_array_query ersetzt.
Intern wird nun die DBI-Funktion selectcol_arrayref verwendet, anstatt
dies manuell per Schleife zu machen. Der Name selectall_array_query war
irreführend und der neue Name entspricht nun dem, was man erwartet.
G. Richardson [Thu, 14 Feb 2019 11:01:10 +0000 (12:01 +0100)]
Inventory Controller - Datenbankoptimierungen für mini_journal
Aus Datenbanksicht war das Inventory mini-journal eine Katastrophe.
Die trans_id Abfrage führte zu einem ersten Seq Scan auf der Tabelle inventory.
my $query = 'SELECT trans_id FROM inventory GROUP BY trans_id ORDER BY max(itime) DESC LIMIT 10';
Die Rose Manager Abfrage führte dann zu einem zweiten Seq Scan auf der Tabelle inventory:
$objs = SL::DB::Manager::Inventory->get_all(query => [ trans_id => \@ids ]) if @ids;
Das sind zwei Seq Scans auf eine Tabelle die in kivitendo recht groß werden
kann. Außerdem könnte in der Zwischenzeit ein neuer inventory-Eintrag
dazugekommen sein, der damit ignoriert würde.
Im Template wurde dann auf die Rose-Objekte von part, transfer_type, bin und
warehouse zugegriffen, und da diese noch nicht geladen wurden sorgt das im
Extremfall für 40 weitere Datenbankzugriffe.
Das ist alles schön kompakter perl Code, aber wie könnte man das aus
Datenbanksicht optimieren, also die Anzahl der Zugriffe verringern und nach
Möglichkeit Indexe benutzen?
Die Templatezugriffe können einfach durch ein with_objects verhindert werden:
with_objects => [ 'parts', 'trans_type', 'bin', 'bin.warehouse' ],
Statt einer separaten Abfrage für die trans_ids könnte man diese als eine
Unterabfrage in get_all einführen:
query => [ trans_id => [ \"$query" ] ]
Die get-all-Abfrage kann man aber noch weiter verbessern, indem man nach id
statt trans_id filtert, da es für id im Gegensatz zu trans_id schon einen Index
gibt. Das Ziel für die Unterabfrage sollte also sein, eine Liste von ids zu
bekommen, damit der Index benutzt wird und man sich den Seq Scan spart.
Das mini-Journal zeigt die letzten 10 Lagerbewegungen, die entweder
Einlagerungen, Auslagerungen oder Umlagerungen sein können. Im Fall von
Umlagerungen wären das 2 inventory-Einträge, ansonsten 1. Da wir nicht wissen,
wieviele Umlagerungen dabei sind, holen wir die letzten 20 Einträge, filtern
diese nach den letzten 10 trans_ids, und extrahieren daraus die inventory ids
(zwischen 10 und 20 ids). Die ursprüngliche Abfrage mit dem GROUP BY konnte
keinen index nutzen, da das ORDER BY auf max(itime) statt itime war. Durch das
"limit 20" werden zwar potentiell ein paar Zeilen zu viel geholt, dafür kann
man aber nun einen Index auf inventory(itime) setzen, der von der Abfrage auch
verwendet werden kann, und damit spart man sich auch den letzten Seq Scan auf
inventory.
create index if not exists inventory_itime_idx on inventory (itime);
G. Richardson [Tue, 22 Jan 2019 13:56:24 +0000 (14:56 +0100)]
Spalte taxnumber aus Tabelle tax entfernt
tax.taxnumber war ein redundanter Eintrag, und entsprach dem Wert von
chart.accno aus tax.chart_id.
Z.B. in SKR04 hatte Steuerschlüssel 3 (Umsatzsteuer 19%) die taxnumber
1776 und die chart_id 775 (chart mit id 775 ist das Konto 1776).
Ein Problem dabei ist, daß wenn man in den Konteneinstellungen die
Kontonummer von 1776 ändert, dies nicht automatisch in tax.taxnumber mit
aktualisiert wurde.
Im Code wurde taxnumber v.A. verwendet, um bei Belegen die Steuern zu
gruppieren, mit der taxnumber als Schlüssel.
taxnumber wurde nun also entfernt, und obwohl zum Gruppieren der Steuern
immer noch diese Kontonummer verwendet wird, wird diese Kontonummer
nicht mehr zum Suchen des entsprechenden Taxeintrags verwendet, sondern
die Suche passiert indirekt über die chart_id.
Das ganze System basiert derzeit darauf, daß es für jeden tax-Eintrag ein
eindeutiges Automatikkonto gibt, in der Praxis muß dies aber nicht der
Fall sein!
PTC: zur Margenberechnung die Nettozeilensumme nehmen.
So ist der Verhalten in den anderen (alten) Masken. Sonst ergeben sich
unterschiedliche Werte in den verschiedenen Masken, wenn
"Steuer im Preis inbegriffen" gewählt ist.
Jan Büren [Wed, 24 Jul 2019 07:45:35 +0000 (09:45 +0200)]
EB/SB Buchungen minimale Kindersicherung für Datumswerte
Die Funktion lässt den Nutzer zuviele Freiheiten ;-(
Ausreichend wäre es nur ein Datum (vgl. sql-ledger yearend) eingeben
zu lassen und das Folgedatum ist dann automatisch der nächste Tag.
Moritz Bunkus [Mon, 22 Jul 2019 09:36:59 +0000 (11:36 +0200)]
Hintergrundjobs: einmalige Jobausführung: Daten übergeben können
Entweder, man übergibt `data` als Parameter in
URI-Hash-Form (z.B. '&data.var=value'), als normaler YAML-encodierter
String, so wie er auch in der Datenbank
steht (z.B. '&data=---%0Avar%3Dvalue'), oder man übergibt
JSON-encodierte Daten in
`json_data` (z.B. '&json_data=%7B%22var%22%3A%22value%22%7D`).
Moritz Bunkus [Thu, 18 Jul 2019 08:31:12 +0000 (10:31 +0200)]
CVars: bei Gültigkeitswechsel aktuellen Wert nicht speichern
Wenn man in den Artikelstammdaten eine CVar von ungültig auf gültig
umschaltet, so ist in dem Moment die CVar-Input im Formular nicht
enthalten, sondern nur die Gültigkeits-Checkbox. Wenn dann im Backend
der aktuelle Wert der CVar in die DB gespeichert wird, weil die CVar
ja ab dem Moment gültig ist, so ist der Wert dementsprechend leer
bzw. 0 für numerische Typen.
Der Effekt ist, dass beim nächsten Laden der CVar ein Wert in der DB
steht (leer/0), und dass dieser Wert vorausgewählt ist und nicht der
Standardwert aus der Konfiguration.
Daher sorgt diese Änderung dafür, dass in so einem Fall der aktuelle
CVar-Wert schlicht gar nicht in die DB geschrieben wird. Genauer:
Wenn das Speichern der Gültigkeit gewünscht wird, so wird der Wert nur
dann geschrieben, wenn die CVar sowohl vor dem Speichern als auch nach
dem Speichern gültig ist, sie also weder gerade aktiviert noch gerade
deaktiviert wird. Andernfalls wird die CVar in der DB nicht vorhanden
sein.
Moritz Bunkus [Wed, 17 Jul 2019 13:48:13 +0000 (15:48 +0200)]
Einkauf/Verkauf: keine Validierung bei Update-Button
Andernfalls wird z.B. erzwungen, dass die Vorgangsbezeichnung
eingegeben ist, bevor der Update-Button betätigt wird. Das betrifft
auch den Kundenwechsel, der ein automatisches Update triggert, was
wiederum die Validierung triggert.
Wichtig bzgl. Validierung ist letztlich nur, dass die Werte zum
Zeitpunkt des Speicherns gültig sind, egal ob explizites
(»Speicher«, »Als neu speicher«) oder implizites Speichern (»Drucken«,
»E-Mail« etc.).
Moritz Bunkus [Tue, 16 Jul 2019 12:26:29 +0000 (14:26 +0200)]
LaTeX: openin_any weniger restriktiv
Die Einstellung openin_any aus texmf.cnf (oder der Umgebungsvariable
gleichen Namens) kontrolliert, aus welchen Pfaden (PDF)LaTeX
Quelldateien liest: a = any liest aus beliebigen Verzeichnissen, r =
restricted nicht aus Dot-Verzeichnissen und p = paranoid nur aus
dem Ausgabeverzeichnis und seinen Unterverzeichnissen.
Bei kivitendo ist das Ausgabeverzeichnis …/users, die Vorlagen liegen
in …/templates/…, sind also keine Unterverzeichnisse. Aktuelle
LaTeX-Versionen (zumindest ab TeXLive 2019.5…) wenden das nun strikt
an, was dazu führt, dass z.B. das Einbinden von Bildern nicht möglich
ist, wenn die Bilder in …/templates/… anstelle von …/users liegen —
sogar obwohl …/templates/… in $TEXINPUTS enthalten ist.
An dieser Stelle ist zu viel Sicherheit falsch bzw. für unser
aktuelles Layout falsch.
Eine andere mögliche Variante wäre, die LaTeX-Abhandlung direkt in
…/templates anstelle von …/users uz machen. Das erfordert aber
potenziell Eingriff durch den SysAdmin, um Verzeichnisrechte anders zu
setzen. Daher wird das erst mal nicht gemacht.
CVars in den Warenstammdaten sind nicht immer gültig. Das Problem hier war,
dass das Speichern des Gültig-Flags durch einen anderen Bug nicht funktionierte,
und so Variablen, die als Voreinstellung deaktiviert waren, nicht mehr geändert
werden konnten (auch nicht auf aktiviert/gültig gesetzt werden).
Der Fix für diesen anderen Bug kommt gleich.
Jan Büren [Tue, 9 Jul 2019 10:34:23 +0000 (12:34 +0200)]
Dokumentation: Andere Pakete an zentraler Stelle bündeln
Viele Admins überlesen die Notiz, dass postgresql-contrib noch
benötigt wird, wenn die Info 'nur' im Kapitel Datenbank steht.
Kapitel 2.2.3 unterhalb der Perl-Pakete kurz gebündelt und alle
notwendigen nicht Perl Pakete dort mit einem Installationsbefehl gesetzt.
Auftrags-Controller: item-ids nach Speichern richtig setzen
Vergessen, den idx in jedem Fall weiterzuzählen. Dadurch konnte es passieren,
das Positionen aus dem Auftrag gelöscht und evtl. Langtexte und Werte der
2. Zeile falsch zugeordnet wurden.
projects / kivitendo-erp.git / log