Auftrags-Controller: PartPicker filtert nach Kunden- und Lieferanten-Art.-Nr., …

… sofern das in den Benutzereinstellungen ausgewählt ist.

UserPreferences-Helper f. Part-Picker-Such-Einstellungen in Belegen

Hier kann der Benutzer einstellen, ob in Verkauf auch nach Kunden-Artikle-Nr.
und im Einkauf nach Lieferanten-Artikel-Nr. gesucht werden soll.

PartPicker nach Kunden- und Lieferanten-Artikel-Nr. suchen und filtern können

Part: Filter-Specs für Kunden- und Lieferanten-Artikel.-Nr.

PartPicker: Mehrfachauswahl: Ursprüngliche Filter für Dialog merken.

Damit klappt das auch hier mit der Suche nach gültigen/ungültigen/allen
Artikeln.

Release 3.5.4

Changelog auf Release 3.5.4; Bugfixes ergänzt

locales-Lauf english

Vergessene hidden Abteilung für Ein/Verkauf->Berichte->Lieferscheine

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.

Task-Server: Exceptions als Warnung loggen, nicht als Debugmeldung

DB-Upgrade-Skripte: Falsche Abhängigkeit 3.5.2 -> 3.5.4 korrigiert

3.5.3 -> 3.5.4

Release 3.5.4-beta1

Changelog auf Release 3.5.4-beta gesetzt

Dokumentation: Release auf 3.5.4 gesetzt

Datenbank-Upgrade-Skripte für die 3.5.4

generische LS-E-Mail auch in Stammdaten editieren ...

Controller - alten unbenutzten Code entfernt

SL::Dev::Inventory - Typo und Formatierung

descriptin -> description

lange Zeilen in mehrere Zeilen umformatiert

Typo in POD

Typo in POD

DBConnect POD Typo

ungenutzte Spalte "ranking" aus Tabelle "payment_terms" entfernt

Überbleibsel aus uraltem Zahlungsbedingungsfeature

action Name in POD aktualisiert

SL::DB _register_db Passwort aus $type herausfiltern

Es wurde nach dem falschen String gefiltert.

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.

Kontoauszug verbuchen rückgängig: Mitarbeiter in history protokollieren

Kontoauszug rückgängig machen: Nur bei aktuellem Beleg arap.paid neu setzen

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`).

Mahnungs-Tabelle: Fremdschlüsselverknüpfung auf Rechnungstabelle Part 2

Mahnungs-Tabelle: Fremdschlüsselverknüpfung auf Rechnungstabelle

DateTime: Funktionen zum Parsen von YYYY:MM:DD und YYYY:MM:DDTHH:MM:SS

Hintergrundjobs: Controller-Action zur einmaligen Ausführung eines Jobs

Gedacht für Aufruf von extern, gibt JSON zurück. Beispiel:

curl --silent  --user "<username>:<password>" \
  'https://<hostname>/kivitendo/controller.pl?action=BackgroundJob/execute_class&class=CleanAuthSessions'

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.

Einkauf/Verkauf: Bemerkungsfelder gleich groß anzeigen

Einkaufsrechnungen: Projektauswahl gefixt

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.).

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.

Part-Controller: Kosmetik

Part-Controller: Gültigkeit von CVars richtig speichern

Das behebt den Bug, dass sich CVars in den Warenstammdaten nicht mehr
ungültig/gültig gesetzt werden konnten.

Revert "CVars: in Artikelstammdaten sind alle CVars gültig"

This reverts commit ab45df2fa087f4b754ef02f238557ab0e28a676b.

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.

Upgrade-Datei: Hinweis auf: Task-Server berücksichtigt Memory-Limit

Changelog: Task-Server berücksichtig Memory-Limit

Dokumentation: Task-Server: Hinweise auf Memory-Limit und Restart (systemd)

Ausserdem alle "Taskserver" durch "Task-Server" ersetzt.

Task-Server: Debug-Meldung, falls Beendigung wg. Memory-Limit.

memory_usage_is_too_high von Dispatcher nach System::Process verschoben

(cherry picked from commit c0e3364a21b2da1c61564ddb8d9afa5ab6489f9c)

task_server.pl: Speicherlimit beachten

(cherry picked from commit 7fcf2ca9960d160419aa89824cb4fb3a25188ad9)

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.

Dokumentation: weitere Anpassung für openSUSE

SuSE Installations-Doku überarbeitet

Bugfix: Brieffunktion prüft im Einkauf auf Verkaufsbriefrechte

Ternärer Operator für Fallunterscheidung
(is_sales or is_not_very_much_sales)

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.

Nachtrag zu:
commit 7749e0e61e5d431a59e33cf497addf9ad682b8af
Author: Bernd Bleßmann <bernd@kivitendo-premium.de>
Date:   Wed May 15 15:18:21 2019 +0200

    OrderController: nach Speichern hiddens der ids wieder setzen, …

    … falls die Makse nicht neu geladen wird.

Benutzereinstellungen für Höhe des Scrollbereichs f. Positionen …

… im neuen Auftrags-Controller

Auftrags-Controller: Einstellungen/Höhe des Scrollbereichs berücksichtigen …

… für den Positionsbereich

UserPreferences-Helper f. Scrollbar-Einstellungen in Belegen

Hier kann die Höhe des scrollbaren Postitionsbereichs im neuen
Auftrags-Controller abgelegt werden.

Changelog (Bei DB Verwendungszweck)

Kontoauszug verbuchen, bei DB Verwendungszweck übernehmen

Dialogbuchungen aus Kontoauszugs-Import erstellen,
der Verwendungszweck wird in die Beschreibung übernommen

Dialogbuchungen aus Bankimport nicht stornieren

Die acc_trans_ids werden hier auch noch gelöscht und
neu geschrieben. Die Verknüpfungs-Info gehen entsprechend kaputt.
Solange die Periode noch nicht geschlossen ist, ist ein Neuverbuchen
der Bankbewegung wesentlich sinnvoller.

PartPicker: auch nach ungültigen oder allen Artikeln suchen können.

Dazu kann ein Parameter "status" (active/obsolete/all) übergeben werden.
Ohne diesen Parameter ist das Verhalten wie zuvor (nur gültige).

Wiederkehrende Rechnungen: Druckvorlage nach Auftragssprache auswählen

Bisher wurde immer die Standarddruckvorlage genutzt und die im Auftrag
und damit der Rechnung eingestellte Sprache komplett ignoriert.

Weiterhin wird der Dateiname des Anhangs nach der eingestellten
Sprache gesetzt. Das funktioniert nur, wenn die in kivitendo
konfigurierten Sprachen dieselben Sprachkürzel nutzen, wie kivitendos
Übersetzungen selber heißen (also »de« und »en«).

LXDebug: fix level2string für diverse Level, inklusive WARN()

Task-Server: CLI-Option zur Ausführung eines einzelnen Jobs

Führt einen einen bestimmten Job exakt einmal aus, egal, ob der Job
aktiv ist oder was sein nächstes Ausführungsdatum ist. Anschließend
beendet sich der Task-Server wieder.

Das Argument ist die Datenbank-ID aus Tabelle »background_jobs«.

Beispiel:

./scripts/task_server.pl debug --run-job=42

Admin-Controller: Anlegen der Vollzugriffs-Gruppe gefixt

Nach dem Anlegen einer neuen Auth-DB und neuer Session-Tabellen sollte
eigenlich auch eine Gruppe namens »Vollzugriff« angelegt werden, die
Zugriff auf alle Funktionen bekommt — wurde sie aber nicht.

Es gab gleich zwei Probleme mit dem Code:

1. Die Funktion »apply_dbupgrade_scripts« gab nach dem Anlegen der
   Session-Tabellen den Wert 1 zurück (im Sinne von »es wurden
   DB-Upgrade-Scripte angewandt«). Das hat der aufrufende Code aber
   als Gelegenheit genutzt, um den Request zu beenden, bevor der Code
   zur Prüfung, ob es schon Gruppen gibt, überhaupt ausgeführt wurde.

   Hintergrund ist, dass
   »SL::DBUpgrade2->apply_admin_dbupgrade_scripts« selber schon eine
   Webseite rendert und die aufrufende Funktion im Controller das dann
   nicht auch noch machen wollte.

   Doof nur, dass diese Funktion im Controller dann nie wieder
   aufgerufen wurde.

2. Der Test, ob es schon eine Gruppe gibt oder nicht, war falsch. Der
   Code sollte eigentlich eine beliebige Gruppe auslesen und der
   Variablen »$group« zuweisen. Was der Code aber gemacht hat, war eine
   Referenz auf ein leeres Array der Variablen zuzuweisen. Der
   nachfolgende Check auf »ist $group nicht gesetzt?« hat dann
   natürlich nicht gegriffen, denn auch eine leere Array-Referenz ist
   im Perl-Sinne wahr.

Admin-Controller: falscher Funktionsname für Auth-Variablen gefixt

Die Umstellung auf Auth-Handler mit Einführung der Möglichkeit, sich
auch über HTTP-Basic-Authentifizierung anzumelden, hat als Änderung
mitgebracht, dass die
Authentfizieriungsvariablen (z.B. »{AUTH}admin_password«) nicht mehr
in $::form verbleiben. Einige Controller benötigen diese aber;
z.B. der Admin-Controller, wenn es noch keine Auth-DB oder keine
Session-Tabellen gibt — denn dann ist die einzige Möglichkeit, das von
der Benutzer*in eingegebene Admin-Passwort über mehrere Requests zu
erhalten, es in der Form mitzuschleifen.

Der Admin-Controller war darauf auch schon vorbereitet — leider hatte
aber die Funktion, die diesen Umstand mitteilt, den falschen Namen und
wurde somit niemals aufgerufen.

Dies ist der zweite Teil des Fixes von #376.

SessionValue: damit klarkommen, dass Auth-DB & Session-Tabellen nicht existieren

Durch die Änderungen letztens, mit der Session-Werte auch bei parallel
laufenden kivitendo-Requests richtig erhalten bleiben, wurde
SessionValue so umgeschrieben, dass es davon ausgeht, dass sowohl die
Auth-DB als auch die Session-Tabellen immer existieren.

Dies ist jedoch während der Erstinstallation nicht der Fall. Diverse
Requests im Admin-Controller müssen ausgeführt werden können, damit
Auth-DB & Session-Tabellen über den Controller angelegt werden können.

Da der Admin-Auth-Handler aber auch mit Sessions funktionieren kann,
fragt er also Session-Werte ab; die wiederum versuchen,
SessionValue-Instanzen zu nutzen.

SessionValue prüft nun bewusst auf Präsenz der Session-Tabellen, bevor
es versucht, aus ihnen zu lesen.

Dies ist Teil des Fixes von #376.

Mailer: Encoding der Namen von Dateianhängen gefixt

Email::MIME encodiert den Dateinamen, der im »Content-Disposition«-
Header enthalten ist, nicht selber. Daher muss der Aufrufer das
tun. Andernfalls kann es bei Nicht-ASCII-Zeichen dann dazu kommen,
dass das empfangene Mail-Programm diese in einem anderen Zeichensatz
interpretiert (z.B. ISO-8859-1), obwohl wir immer UTF-8 senden. Ein
Halleluja für Legacy-Standards.

Weiterhin gibt es einen subtilen Bug in Email::MIME. Eigentlich steht
der Dateiname ja bereits im »attributes«-Hash, das an
»Email::MIME->create()« übergeben wird. Hier könnte man den Dateinamen
schon encodiert reinschreiben.

Das funktioniert auch — aber nur manchmal. Intern scheint das Modul
über die Hash-Keys von »attributes« zu iterieren und je nachdem,
welche Keys es schon gesehen hat, das vom Aufrufer vorgenommene
Encoding rückgängig zu machen. Da die Hash-Key-Reihenfolge aber bei
jedem Aufruf von Perl zufällig gewählt wird, passiert es halt
manchmal, dass diese Keys bereits gesehen wurden und Email::MIME das
Encoding rückgängig macht.

Daher muss der »Content-Disposition«-Header unbedingt nach dem
Erzeugen mit »create« gesetzt werden. Dann lässt Email::MIME ihn auch
genau so, wie er sein soll.

Periodische Rechnungen: find_template-Aufruf gefit

find_template gibt je nach Kontext (Skalar vs. Array) unterschiedliche
Dinge zurück. Innerhalb einer Hashzuweisung herrscht Array-Kontext,
und damit kann je nach Reihenfolge, in der die Hash-Parameter von Perl
ausgewertet werden, der gesamte Hashinhalt schrott sein.

Module: weitere Anpassungen für Exception::Lite → Exception::Class

Druckvorlagen RB Syntax-Fix für notes (VK-Angebot)

Ist aus Versehen mit der letzten Überarbeitung reingekommen.

Doku: Apache 2.2 Direktiven entfernt

Der Hinweis für ältere Versionen ist ausreichend.
Entsprechend entfernt.

Doku: ghostscript als Paket für LaTeX ergänzt

Die Mahnungen benötigen dieses Paket

Session Content: Query zum Einlesen gefixt

Operatorpräzedenz wurde falsch berücksichtigt.

Session Content: Race condition gehoben

Der ursprüngliche Mechanismus hat einfach nur alle Session Variablen
gespeichert und beim Session restore wieder geladen. Es hat sich aber
gezeigt, dass große Daten in der Session Requests deutlich langsamer
machen, also wurde das Flag auto_restore eingeführt. Session Werte, die
nicht automatisch benötigt werden, sollten dann nur bei Bedarf geladen
werden.

Um zu wissen welche Werte existieren wurden aber zum Start des
Requests einmal alle Werte aus der Sessiontabelle geholt, und am Ende
dieser Stand auch wieder hergestellt.

Unter ajax load kann es aber passieren, dass in der Zeit andere Requests
schon Werte eingepflegt haben die dabei gelöscht werden. Das führt dann
zu zufälligen Sessionabbrüchen oder Requestfehlern.

Jetzt werden am Anfang nur und ausschließlich die Daten geladen die auch
auto_restore sind, die dann auch gleich gelöscht werden. nur die Daten
die modifiziert werden, werden am Ende des Requests zurückgespeichert.

Es wäre toll gewesen dafür ein UPSERT zu nehmen, aber das scheitert
daran, dass das ein DB Upgrade auf auth braucht.

OrderController: nach Speichern hiddens der ids wieder setzen, …

… falls die Makse nicht neu geladen wird.

OrderController: Kosmetik

Sessions: keine Prüfung der Quell-IP-Adresse

Wenn ein Hostname sowohl A- (IPv4) als auch AAAA-Records (IPv6)
aufweist, nutzen manche Reverse Proxies wie nginx mal IPv4, mal
IPv6. Dadurch prüft kivitendo manchmal (nämlich genau dann, wenn die
Verbindung über IPv4 reinkommt) die Quell-IP. Wurde die Session aber
initial über IPv6 erzeugt, so schlägt die Quell-IP-Prüfung natürlich
fehl.

Die Quell-IP-Prüfung liefert eh einen mehr als fragwürdigen Gewinn an
Sicherheit. Für IPv6, wo sich die Quell-Adresse aufgrund von Techniken
wie Privacy Extensions mitten in der Session ändern kann, haben wir
die Prüfung ja eh schon nicht mehr.

Doku: Installations-Anmerkungen für Debian/Ubuntu ergänzt

Doku: debian 10 getestet

Doku: fix copy-paste Fehler libyaml-perl

Installation-Doku typo libdatetime-event-perl -> libdatetime-event-cron-perl

Merge branch 'f-bundled-perl-modules'

Module: Dokumentation angepasst

Module: implizite Anforderung auf Set::Crontab entfernt

kivitendo nutzt das Modul nicht direkt, sondern nur
DateTime::Event::Cron. Das nutzt Set::Crontab unter der Haube, weshalb
wir keine direkte Abhängigkeit deklarieren sollten.

SL::DB::Cache nach SL::DB::Helper::Cache verschoben

Da es sich nicht um eine Mapping-Klasse einer Tabelle handelt, sollte
sie nicht direkt innerhalb von SL::DB liegen.

Typo: Schwellenwert statt Schwellwert

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

PDF::Table - einige undefined warnings gefixt

PDF::Table: Warnungen und "-" Artefakte bei undef entfernt

PDF::Table: Zusätzliche header richtigrum anzeigen

PDF::Table: Prop Index korrekt indizieren

PDF::Table: Proportional skalieren statt adaptiv

PDF::Table: Rahmen bei umgebrochenen Zeilen in der korrekten Länge zeichnen.

Endlosschleife im PDF-Tabellenmodul und damit im PDF-Export gefixt

Wenn die Tabelle zu breit wird und dann irgendwann nicht einmal mehr ein
Wort in eine Zeile passt, dann muss das Wort trotzdem gesetzt werden;
andernfalls würde das PDF::Table-Modul in einer Endlosschleife enden.

Fix für Bug 863.

Reimplementiert commit 23223ef4302931a6a141c659bfda7ef6c7546b77

ReportGenerator: Unterstützung für das Verbinden von Tabellenzellen mit dem "colspan"-Attribut in der PDF-Ausgabe.

Reimplementiert a18cc3f5dedae1c8b541b10df3b67153518663a6

ReportGenerator: Unterstützung für mehrzeilige und individuell festgelegte Tabellenköpfe/Spaltenüberschriften implementiert.

Reimplementiert den PDF/Table.pm Teil von 84ba8214f6f1e68de5fa317b8239a7888a4aac03

Unterstützung für zellenübergreifende Überschriften im PDF-Export des ReportGenerators verbessert.

Reimplementation von d3897394/35cd4452.

Module: Update von PDF::Table auf 0.10.1

Module: 'modules/fallback' nicht mehr in @INC aufnehmen

Module: Dokumentations-Update

Module: Exception::Lite durch Exception::Class ersetzt