projekt kivitendo

Zeiterfassung: Recht berücksichtigen, Einträge von anderen (nicht) zu sehen

time-recording: Boolean für abgerechnete und an die LohnBu gemeldete Zeiten

Zeiterfassung: Defaultfilter: aktueller Benutzer, letzte 2 Wochen

Zeiterfassung: Nur nicht-gelöschte Mitarbeiter angezeigen

Zeiterfassung: Ein Recht dafür

Zeiterfassung: Controller

Zeiterfassung: SimpleSystemSettings für Typen

Zeiterfassung: Sortierung und Ordnung für Typen

Zeiterfassung: Tabellen und Rose

POD für ClientJs aktualisiert

Order: Warnung/Fehler bei Liefertermin auch bei kombinierten Export-Aktionen

Order-Controller: Neue Action preview_pdf (Druckvorschau für PDFs)

Artikel-BDVs unter Basisdaten anzeigen, falls konfiguriert

Die benutzerdefinierten Variablen für Artikel können konfigurierbar im Tab Basisdaten
angezeigt werden

locales Lauf "de" überwiegend Shopübersetzungen

Dateianhänge aus Projekten auch in E-Mail anzeigen

In Anlehnung an odyn fa2f21bb7d9247782f5e
Im E-Mail-Dialog werden hochgeladene Dateianhänge aus einem
globalen Projekt angeboten und sind vorausgewählt.

Projekte: Dateianhänge auch für Projekte

Cherry-pick aus odyn (Upgrade Skript entsprechend geändert)
implemntiert EGW #6889

ReportGenerator: Get PDF as binary (no print, no http-redirect)

Shoconnector Syntaxfehler behoben

SHOPOrders Status setzten bei Rechnungen korrigiert

ShopApi: statussetzen bei Rechnung schreiben Syntaxfehler behoben

ShopConnector: set OrderStatus in Shop

WebshopApi: Controller/ShopOrder.pm überarbeitet

WebshopApi: ShopConnector überarbeitet

CSV-Import CustomerVendor: Warnungen wegen nicht initialisierter Variable vermeiden

CSV-Importe: Warnungen wegen nicht initialisierter Variable vermeiden

CsvImport: Mulitplex: handle_cvars-Routine verlassen, wenn Objekt keine CVars kann

CsvImport: Bei Imports ohne CVars deren Standard setzen, wenn vorhanden.

CsvImport: Parts: CVars von handle_cvars behandeln lassen.

Dabei aber beachten, dass das bei einen Import, wo nur die Preise aktualisiert
werden sollen, nicht geschieht.

CSV-Import: CustomerVender benutzerdefinierte Variable aktualisieren

handle_cvars erst aufrufen, wenn das zu speichernde Objekt bekannt ist. Das
betrifft den Fall, wenn vorhandene Objekte aktualisiert werden sollen.

behebt #237 (redmine)

CsvImport: handle_cvars: CVars für das zu speichernde Objekt setzen.

Revert "CSV-Import: CustomerVender benutzerdefinierte Variable aktualisieren"

This reverts commit a8628c6af6ab8303fe67d874adbee0211bd86c1e.

Hier wird das eigentliche Problem nur umgangen.
Zudem, wie im commit schon erwähnt, sollte handle_cvars nur einmal aufgerufen...

CsvImport: CustomerVendor: Nummer vom Helper des Objekts vergeben lassen.

Vorher wurde hier SL::TransNumber verwendet - das ist kein Problem, aber die
es den Helper gibt, ist das hier einfacher.

Zudem wurde vorher auch eine neue Nummer für die zu aktualisierenden Objekte...

CsvImport: Im Report die Werte des gespeicherten Objekts speichern.

Bei den Workern, die Objekte aktualisieren können, kann statt dem object
das object_to_save gespeichert werden. Die Werte dieses Objekts sollten im
Report angezeigt werden, auch wenn die eigentlich gleich sein müssten....

Dateimanagement: größere Vorschaubilder: Versionen berücksichtigen

zu 52f5223a1dcf, mehr als einen Filter im SQL-Statement erlauben

Mahnungsbericht: Anzeige f. Dokumente/Mails abschaltbar

Mahnungsbericht: E-Mails f. Mahnungen anzeigen

Verknüpfung zum E-Mail-Journal für Mahnungen.

Mahnungen: Rechnungsnummer der Mahnrechung im PDF-Dateinamen statt dunning_id

Der Dateiname wird auch als Name des Anhangs bei Mailversand verwendet und dann
sieht es besser aus, wenn der Name auch mit der Rechnunsgnummer übereinstimmt.

Mahnungen: Status-Bericht nach Mahnlauf mit evtl. Fehlermeldungen.

Das Erzeugen der Mahnungen erfolgt je nach ausgewählten Rechnungen in mehreren
Schritten (Zusammenfassen je Kunde und Mahnlevel oder auch einzeln für jede
Rechnung).
Hierbei können in einem Schritt durchaus Mahnungen für einen Kunden oder einen...

Mahnungen: PDF an Drucker schicken: Druckbefehl erst prüfen, dann verwenden

Einfachen Presenter f. Webdav-Objekte

SL::Presenter::FileObject: link_tag verwenden

S:P:Dunning: Link führt nicht mehr zum Drucken, sondern zum Mahnungsbericht, …

… gefiltert für diese Mahnung. Hier kann man die Details sehen und auch drucken.

S:P:Dunning: Link mit link_tag erzeugen

S:P:Dunning: unbenutzten Parameter "type" entfernt

Mahnbericht: Nach Mahnungsnummer filtern können und diese Anzeigen

Mahnungsbericht: zweite Sortierung (fast) immer nach Mahnungslauf …

… bzw. dunning_id. Damit bleib das Zusammenfassen mehrer Rechnungen eines
Laufes beim Sortieren erhalten, falls möglich.

Mahnungen: DMS/WebDAV: erzeugte Dokumente nach Mahnlauf ablegen.

Und zwar außerhalb der Transaktion und nur wenn diese erfolgreich war,
sonst können bei eine abgebrochenen Transaktion abgelegte Dokumente
vorhanden sein, ohne das eine Mahnung oder Mahnrechnung in der DB existiert.

Mahnungen: DMS/WebDAV: erzeugte Dokumente zum Mahnlauf ablegen …

und nicht zur gemahnten Rechnung.

Dateimanagement: Mahnung: Mahnrechnung bekommt Typ dunning_invoice statt dunning

Hintergrund: Es soll umgestellt werden, dass bei einem Mahnlauf erzeugte
Dokumente zur Mahnenden Rechnung gespeichert werden. Sattdessen sollen diese
zum Mahnlauf gespeichert werden. Dazu wird dann der object_type "dunning"...

SL::Auth: Typo in Methodennamen korrigiert: create_unique_sesion_value …

-> create_unique_session_value

MT940: Zeichensatz der Datei bei Import auswählen können

MT940: Multi-Line-Varianten von Tag 86 unterstützen

Presenter: SL::Presenter::FileObject in ALL laden

Mahnungen: beim erneuten Drucken ggf. auch originale Rechnung mit drucken, …

… sofern diese beim Mahnlauf mit gedruckt wurde.

Mahnungen: merken, ob die originale Rechnung gedruckt wurde: DB+Rose

SL::DN: print_original_invoices in print_original_invoice umbenannt, …

… da nur eine Rechnung gedruckt wird.

SL::DN: überflüssigen Parameter dbh für print_original_invoices entfernt

Mahnungen: alle erzeugten Dokumente zu jeder gemahnten Rechnung ins WebDAV

Mahnungen: DMS: orig. Rechnung als eigenen Typ

Mahnungen: alle erzeugten Dokumente zu jeder gemahnten Rechnung im DMS ablegen

Dazu die Dateien nicht mehr in SL::Form::parse_template speichern lassen,
sondern in SL::DN selber für jede gemahnt Rechnung ablegen.

Mahnungen: PDF d. Rechnung über Mahngebühren im DMS speichern

Die Id der zugehörigen Rechnung ist in $invoice_id,
nicht in $form->{invoice_id}.

Mahnung per Mail: auch Rechnung über Mahngebühren anhängen

Der Mailer erwartet den Pfad für das Attachment mit dem key "path",
nicht "filename".
Zudem übersetzten Anhang-Namen verwenden.

Mailer: unbenutzen Code entfernt

Dateimanagement: Download-Aktion: Version richtig interpretieren

Dateimanagement: Fileystem-Backend: aussagekräftigere Fehlermeldung

File-Helper: unbenutzten Parameter file_number entfernt

Mahnungsbericht: Erzeugte Dokumente anzeigen

einfacher Presenter für SL::File::Object

Mahnungsbericht: letzte Sortierung immer nach Mahnungslauf …

… bzw. dunning_id. Damit bleib das Zusammenfassen mehrer Rechnungen eines
Laufes beim Sortieren erhalten, falls möglich.

Order: Vorbelegte E-Mail-Texte für Fall Ansprechpartner aktiviert

Dateimanagement: größere Vorschaubilder beim Drüberfahren

S:C:H:ThumbnailCreator: Thumbnail-Größe übergeben können

Dateimanagement: Thumbnails erzeugen und anzeigen

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

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

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

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

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> </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

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">