Dateimanagement: Thumbnails erzeugen und anzeigen

Dateimanagement: Upload per Drag/Drop

Dateimanagement: Hochladen als andere Quelle f. EK-Belege

Also dort, wo bisher auch der Import vom Scanner möglich ist.

S:C:File: Import (scanner): Debug-Warnung, wenn Verzeichnis nicht geöffnet werden kann

Kosmetik: Auftrags-Controller: js: Einrückung und Position der Funktion

E-Mail-Dialog: Knopf E-Mail senden ausgrauen um mehrfaches Senden zu verhindern

 Author:    Jan Büren <jan@kivitendo.de>

Einkaufsrechnungen: Vorgangsbezeichnung speichern und danach suchen können

Artikelstamm: "Erneuert am" aus parts_price_history holen …

… und in "Preisänderung am" umbenennen.

Das ganze ist mit Rose gelöst und holt die Preise aus parts_price_history.
Das hat den Nachteil, dass im Artikelbericht nicht nach der Preisanpassung
sortiert werden kann und es wahrscheinlich nicht performant ist.

Der aktuelle Trigger für parts.priceupdate funktionierte nicht, und hätte
auch bei jeder Änderung eines Artikels das Datum angepasst. Dafür kann man auch
mtime nehmen.

Todo 1: Spalte priceupdate (und den Trigger) aus parts löschen (und alle
Vorkommen finden).
Todo 2: Query auf SQL umschreiben und soriteren wieder ermöglichen.

Refs #254 (redmine)

Lieferschein: direktes, erstmaliges Drucken gefixt

Behebt #469 (redmine)

Auftrags-Controller: 2. Zeile: Lagerbestand nicht doppelt formatieren

Entweder format_amount oder _as_number

Behebt #470 (redmine)

Auftrag-Controller: Vergleich des Beleg-Typs einheitlicher …

- Zum Typ-Vergleich die Typ-Funktionen verwenden.
War hier kein Problem, kann aber Typos verhindern - dafür sind die Funktionen
gedacht gewesen.

- Auf type nicht als Hash-Key, sondern als Methode zugreifen.
Dann ist das einheitlicher, da das auch überall sonst im Controller so gemacht
wird.

Kosmetik: Auftrags-Controller: Typo in Funktionsname

Mandantenkonfig: Lieferdatum bei VK-Auftrag und Gültigsdatum bei VK-Angebot

Anstatt diese beiden Werte zu berechnen, gibt es die Möglichkeit
diese konfigurativ gar nicht zu setzen. Hoffentlich letzmalig auch
für die OE.pm implementiert.

Auftrags-Controller: auch bei E-Mail erzeugtes Dokument im WebDAV/DMS speichern

Brief: erzeugtes Dokument im DMS speichern

wiederkehrende Rechnungen: auch bei E-Mail erzeugtes Dokument im DMS speichern

Presenter::Tag: img_tag aus Plugin/L verschoben

Presenter::Tag: radio_button_tag aus Plugin/L verschoben

kivi.File.js: unbenutzte, leere init-Funktion raus

Filemanagement: Web-Templates list: table-End-Tag korrigiert. HTML-Plugin raus

Filemanagement: Web-Templates import: kleinere Fixes …

- nicht benutztes JavaScript-Plugin raus
- keine Tabellen-Tags ausserhalb einer Tabelle

Filemanagement: Web-Templates upload: nicht benutztes JavaScript-Plugin raus

Kosmetik: Filemanagement Web-Templates: Einrückung

Mailer: überflüssigen Nicht-Standard-Header entfernt

Einen Header namens »Type« gibt's nicht. Vermutlich war »ContentType«
gemeint, aber der wird definitiv anders gesetzt und nicht auf
multipart/mixed.

HTML zu LaTeX: gewisse kaputte Konstrukte vom CKEditor entfernen

Dazu gehören leere Listen <ul></ul> oder Paragraphen mit
Zeilenumbrüchen und non-breakable spaces <p><br><br>&nbsp;</p>

MT940: Zeile 61: Felder »Buchungsdatum« und »Währungsart« sind optional

MT940 parse Feld 25 nach östereichischen Vorgaben

Es scheint Konvention zu sein nach zwei // noch die Länderkennung
in Feld 25 zu schreiben und mit der optional gültigen Währung zu enden
Regex um exakt dieses Präfix vor BLZ/Kontoerkennung erweitert

Stammdaten->Berichte->Kunden Abt1 und Abt2 erweitert

Order-Controller: Knopf f. E-Mail-Aktion nach "Speichern und drucken" freigeben

S:C:H:ThumbnailCreator: POD: Modulname korrigiert und leere Abschnitte raus

SL/DB/Helper/ThumbnailCreator.pm wird nicht benutzt

siehe SL/DB/Controller/ThumbnailCreator.pm

File: POD-Korrektur: File-Typen sind singular

Mahnungen: Mit Rechnung verknüpfen

Erstellte Mahnungen werden mit den gemahnten Rechnungen verknüpft und
unter "Verknüpfte Belege" gelistet.
Außerdem werden Rechnungen über Mahnkosten wiederum zu den zugehörigen
Mahnungen verknüpft.

impl. #7440

DBUtils: Prüfung auf Trigram-Erweiterung aus S/D/ShopOrder in DBUtils verschoben

Order-Controller: Historienfunktion implementiert (aufzeichnen & anzeigen)

Order-Controller: Artikelklassifizierung berücksichtigen

GetModels Filtered: neuer Modifer »any« für logisches oder

Kann benutzt werden, um z.B. verschiedene Part-Klassifizierungs-IDs im
Filter zu nutzen:

<input type="hidden" name="filter.classification_id:any" value="0 1 3">

Order-Controller: TODO »credit limit« entfernt

In Besprechung letzte Woche festgehalten, dass wir die Funktion erst
mal nicht wieder implementieren.

Order-Controller: Workflow Lieferantenauftrag → Preisanfrage

Order-Controller: Workflow Verkaufsauftrag → Verkaufsangebot

SL::DB::Order: überflüssigen Code entfernt

S:C:Letter: toten Code entfernt

S:C:Letter: kivi.SalesPurchase.js laden

doku: Hinweise für manuelle Konjunktureinstellungen verbessert

Einkaufsbericht: Anzeigefilter um Projektbeschreibung erweitert

Wiedervorlage: alte Masken: Abfangen, wenn z.B. Betreff nicht vorbelegt

Sonst gab es einen js-Fehler und das WV-Fenster erschien nicht.

Kam mit commit 7b447b4dd0e756dc1578c44601d352811b768514
"Wiedervorlage aus Angebot/Auftrag: Betreff aus Vorgangsbezeichnung vorbelegen"
rein.

S:C:Letter: Sprache an Druck-Template weitergeben

SL::File: Debug-Warnung ausgeben, wenn eine Version nicht geholt werden kann

Fehler kann auftreten, wenn z.B. die Datei im Dateisystem nicht lesbar ist.

Auftrags-Controller: Artikel-Mehrfachauswahl-Dialog nicht ohne Kunde/Lieferant

Kunde/Lieferant muss vorher ausgewählt werden

Auftrags-Controller: Artikel-Mehrfachauswahl: js-Code aus Template ausgelagert

Auftrags-Controller: Artikel-Mehrfachauswahl auf die des PartPickers umgestellt

PartPicker: Mehrfachauswahl: Option um Positions-Eingabefed anzuzeigen

Die Eingabe kann im Callback verwendet werden, um die Artikel an bestimmte
Positionen zu setzen.

PartPicker: Ergebnisse f. Mehrfachauswahl: Tabelle alternierend einfärben

PartPicker: Ergebnisse f. Mehrfachauswahl: horiz. Linie so lang wie Tabelle

Kosmetik: PartPicker Template Ergebnisse f. Mehrfachauswahl

PartPicker: Mehrfachauswahl: Option um Anzeige-Begrenzung zu setzen

Diese war vorher fest auf 100 eingestellt. 100 bleibt die Voreinstellung.

PartPicker: Option für Mehrfachauswahl als default merken

Damit lässt sich die Option via js ändern, um z.B. einen Dialog
mit Mehrfachauswahl über einen Knopf zu öffnen, während die
Funktion der Lupe bei der Einfachauswahl bleibt (oder andersherum).

Langtext-Dialog: HTML-Template: Kein Paragprah (<p>) um Tabellen (<table>)

POD fix: Rose Syntax im Beispiel

Vergleichsoperatoren werden als Hash-Ref angegeben.

Revert "POD fix: Rose Syntax"

ilike gibt es doch.

This reverts commit 95f21f71c1c5c2f6cf6a281a0174d8f247be1135.

Erzeugnis-Stammdaten: Artikelliste: Summenzeile richtig platziert

Diese Zeile war verschoben.

nochmal locales-Läufe

- de -> Reihenfolge
- en -> fehlte

Syntaxfehler behoben

kam rein mit commit d919a7dcc958edf6c7cd2546690347ea9c157f6e
(all_parts Erzeugnis EK als separate Spalte im Bericht)

Locales für vorherigen Commit

all_parts Erzeugnis EK als separate Spalte im Bericht

Problem: Bei der Mischauswahl von Waren und Erzeugnissen in
dem Bericht erscheinen dann Waren mit dem EK des Erzeugnisses, der
ggf. 0 sein kann. Das irritiert stark, deswegen lieber eine extra
Spalte für den Erzeugnis-Fall spendieren und den EK bei Waren als
Spalte so lassen.

Artikelliste, Optionen erweitert um Typ (Dienstleistung, E, W)

Je nach Typ liefert der Bericht unterschiedliche Ergebnisse (all_parts),
zumindestens sollten die Filteroptionen als visuelle Hilfe sichtbar sein

PartPicker: Ergebnisse im Dialog nach Blättern initialisieren.

Sonst kann man nur auf der ersten Seite Ergebnisse auswählen.

Behebt #462 (redmine)

Lagerbestand: alle reihen anzeigen auch nach dem Filtern aktiv (hidden vergessen)

Standardlagerplätze in Part sortiert anzeigen

Projekt-Picker für Berichte: auch inaktive und ungültige Projekte zeigen

Projekt-Picker: exact match auf GetModels umgestellt

Projekt-Picker-Lupe: changelog

Projekt-Picker-Lupe: Übersetzungen

Projekt-Picker: weitere Elemente auf der Testseite

Projekt-Picker: Parameter f. aktiv/gültig

und Filter-Daten via data an js übergeben

Projekt-Picker-Lupe: erste Ergebnisse direkt anzeigen

Spart einen zweiten Ajax-Aufruf

Projekt-Picker-Lupe: Copy/paste und Anpassungen vom Chart-Picker

Projekt-Picker: js: $type wird nicht gebraucht

Zahlungsbedingungen Kreditorenbuchung leere Werte mit conv_i abfangen

Zu ZB bei Kreditorenbuchung - Vorbelegung Stammdaten Lieferant

Falls kein invoice_obj vorhanden, wieder auf form->payment_id gehen,
da hier die Werte aus den Stammdaten des Lieferanten vorbelegt sind (!)
Jetzt müssten alle Fälle passen:
1. Gespeicherte Werte anzeigen, auch bei ungültigen ZB
2. Lieferanten-Werte aus Stammdaten übernehmen
3. Lieferanten-Werte beim Wechsel des Lieferanten übernehmen

Kommentar zum Payment-Helper

Außer in den Testfällen wird der Helper nicht mit einem
negativen Amount aufgerufen. Im Helper befindet sich etwas
zuviel automagie. Eigentlich braucht man den Param amount nicht,
wird aber überall in kivi übergeben. Eigentlich darf der negativ
sein, verfälscht aber das multiplizieren im Helper.

Zahlungsbedingungen Kreditorenbeleg Speichern und Laden in Maske

Das was Commit 8b5bed7fe5 versprochen hat, jetzt auch in Echt ;-)

BankTransaction: Filter nach Konteninhaber-Namen

Auftrags_Controller: js: hiddens f. Wiedervorlage nur einmal anhängen

Wiedervorlage aus Angebot/Auftrag: Betreff aus Vorgangsbezeichnung vorbelegen

nur "neuer" Controller

Lieferantenbericht: UStID anzeigen lassen können

Kunden/Lieferanten: UStId/Steuernr. eindeutig: changelog

Kunden/Lieferanten: UStId/Steuernr. eindeutig: Prüfung im Controller

Kunden/Lieferanten: UStId/Steuernr. eindeutig: Mandantenkonfiguration

locales-Skript: all/more für js berücksichtigen

Ein Eintrag wird aus all/more genommen, wenn hier vorhanden, sonst aus
all.

locales-Skript: all/more berücksichtigen, …

indem Texte, die ausschließlich dort vorhanden sind, nicht in all
eingetragen werden. Texte, die vorher schon in all sind, bleiben aber
erhalten. Das sind dann (vermutlich) die Texte, die in more für ein
Kundenprojekt eine andere Übersetzung haben sollen (und nicht neu hinzu
kamen).

locales-Skript: POD update

locales-Skript: Option -n / --no-custom-files raus

Funktioniert so ohnehin nicht mehr (wird ignoriert) und -n war doppelt vergeben
(Option n is ambiguous (no-check-files, no-custom-files))

locales-Skript: Kosmetik: Kommentare

- Typo gefixt
- Kommandozeilenparameter nicht im Kommentar: gibt es als Hilfe
  und im POD und waren nicht vollständig

locales-Lauf en

Merge branch 'f-customer-vendor-rights'

Testfall year_end repariert

.. lieber gleich hartkodiert in 2019 bleiben

Quick-Suche: `auth` == undef oder leerer String gefixt

Laut Doku in `SL/Controller/TopQuickSearch/Base.pm` bedeuten undef
oder leerer String als Rückgabewert der Sub `auth`, dass dieses Modul
für alle Benutzer*innen zur Verfügung steht, unabhängig von deren
vorhandenen Gruppenrechten.

Das hat nur nicht funktioniert.

Kundenstammdaten: beim Anlegen Verkäufer*in setzen wenn kein »edit all«-Recht

Personen, die nur »edit«-Rechte, nicht aber »edit all«-Rechte haben,
dürfen nur noch eigene Kunden bearbeiten. Daher ist es sinnvoll, dass
beim Neuanlegen das Feld »Verkäufer*in« bereits auf die aktuelle
Person gesetzt ist.

Kunden-/Lieferantenstammdaten: Berechtigungsmodell gefixt

Neues Modell sieht wie folgt aus:

1. Alle Personen haben Leserechte auf alle Kunden- &
   Lieferantenstammdaten. Das betrifft nicht nur die Stammdatenmasken,
   sondern auch die AJAJ-Autovervollständigung (Kunden-/
   Lieferanten-Picker) oder die Detail-Popup-Fenster in Einkaufs-/
   Verkaufsbelegmasken.

2. Personen mit »edit«-Recht aber ohne »edit all«-Recht dürfen nur die
   eigenen Kundenstammdaten verändern (speichern/löschen), wobei
   »eigen« definiert ist als »aktuelle Person ist Verkäufer*in des
   Kunden«. Neue Kunden dürfen angelegt werden. Bei Lieferanten dürfen
   hingegen alle Stammdaten bearbeitet werden.

3. Personen mit »edit all«-Recht haben Vollzugriff auf alle Kunden- &
   Lieferantenstammdaten.