X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2FUPGRADE;h=dff984db331a91e3fcdfb01ea33d7eff27c1d3d1;hb=bfa674c9d4edc551afa6e27aac6f684a7b8cb656;hp=a4a798a053bd489101a43a453f57e393171fad61;hpb=0d07a683b433c3fd01b1aa94a5860c1053b0e626;p=kivitendo-erp.git

diff --git a/doc/UPGRADE b/doc/UPGRADE
index a4a798a05..dff984db3 100644
--- a/doc/UPGRADE
+++ b/doc/UPGRADE
@@ -1,19 +1,83 @@
 Wichtige Hinweise zum Upgrade von älteren Versionen
 ===================================================
 
-
 ** BITTE FERTIGEN SIE VOR DEM UPGRADE EIN BACKUP IHRER DATENBANK(EN) AN! **
 
+Upgrade auf v3.6.x
+
+Das manueller Korrigieren der Steuer bei Skontoverbuchungen entfällt seit
+dieser Version, da die Steuerkorrektur automatisch gemacht wird.
+
+Ein neues Perl-Modul ist hinzugekommen, Hilfe zum Installieren bietet wie immer
+das Skript 'scripts/installation_check.pl -v'.
+
+  * IPC::Run
+
+
+Upgrade auf v3.6.0
+
+Der 'neue Auftrags-Controller' ist mittlerweile weder neu noch experimentell und
+die entsprechende Mandantenkonfiguration 'Experimentellen neuen Auftrags-Controller'
+verwenden wird bei diesem Upgrade hart auf 'Ja' gesetzt.
+Die alte, noch aktive Auftragsmaske wird in einer zukünftigen Version von kivitendo entfernt
+werden.
+
+Einige neue Perl-Module sind hinzugekommen, Hilfe zum Installieren bietet wie immer
+das Skript 'scripts/installation_check.pl -v'.
+
+  * Neue Perl Abhängigkeiten:
+
+  * Term::ReadLine::Gnu
+  * Imager::QRCode
+  * Imager
+  * REST::Client
+
+
+
+Upgrade auf v3.5.8
+
+Die API für 'Erzeugnis fertigen' wurde geändert:
+Die Einstellung der Mandantenkonfiguration für 'Zum Fertigen wird das Standardlager
+des Bestandteils verwendet, nicht das Ziellager' hat keine Auswirkung mehr.
+Falls dieser Wert auf 'Nein' steht funktioniert das Verfahren wie vorher auch.
+Falls dieser Wert auf 'Ja' steht, muss geprüft werden, ob das Verfahren noch so
+benötigt wird.
+Alternativ kann 'Erzeugnis fertigen' ab dieser Version auch Erzeugnisbestandteile aus
+fremden Lagern (nicht das Ziellager) nehmen. Dies sollte i.d.R. den Prozeß abbilden können.
+
+Die Mandantenkonfiguration 'Standard-Auslagern ohne Prüfung auf Bestand' wird bei diesem
+Versionsupgrade hart auf 'Nein' gesetzt und kann vom kivitendo Administrator selbständig
+wieder auf 'Ja' gesetzt werden. Das Verfahren wird aber prinzipiell in einer zukünftigen
+Version von kivitendo nicht mehr unterstützt werden.
+
+
+Upgrade auf v3.5.7
+  * Neue Perl Abhängigkeiten:
+
+  * Math::Round
+  * Try::Tiny
+
+
+Upgrade auf v3.5.6.1
+
+Die Abwärtskompatibilität zur Lagermengen-Berechnung in Lieferscheinen wurde
+aufgehoben. Wer nicht mit Workflows arbeitet (nicht empfohlen) muss diese
+explizit in der Mandantenkonfiguration wieder aktivieren.
+
+
 Upgrade auf v3.5.6
 
 In dieser Version sind die Mehrwertsteueranpassungen für den SKR03 und SKR04
 ab 1.7.2020 vorhanden. Wer diese Anpassungen schon manuell eingestellt hat, sollte
 die Upgrade-Skripte deaktivieren.
-Dies betrifft diese drei Skripte "sql/Pg-upgrade2/konjunkturpaket_2020*"
+Dies betrifft diese drei Skripte "sql/Pg-upgrade2/konjunkturpaket_2020*", sowie
+ferner das Entfernen der Release-Abhängigkeiten dieser Skripte:
 
-Folgender sed-Einzeiler erledigt das:
+Folgende zwei Sed-Kommandos erledigen das:
 
  sed -i 's/ignore: 0/ignore: 1/g' sql/Pg-upgrade2/konjunkturpaket_2020*
+ sed -i 's/\bkonjunktur[^ ]*//g' sql/Pg-upgrade2/release_3_5_*
+
 
 Alternativ sollten die Datenbank-Upgrade-Skripte gegen einen Testdatenbestand ausgeführt werden
 und der kivitendo-Dienstleister Ihres Vertrauens griffbereit sein.
@@ -47,7 +111,12 @@ Regeldetails:
   RewriteRule .*(\.git|config).*$ - [F,NC]
 </IfModule>
 
-
+Ferner wurde ein Security-Audit der kivitendo Version 3.1 veröffentlicht.
+Hierfür empfehlen wir die Ausarbeitung eines Sicherheitskonzept mit einem kivitendo Partner Eurer Wahl.
+Falls dies nicht möglich sein sollte, weisen wir darauf hin, dass ein SQL-Backup tages- und wochenaktuell
+für einen etwaigen Restore zu Verfügung stehen sollte. Ferner besteht die Gefahr, dass angemeldete
+Benutzer Formfelder mißbrauchen können, Abhilfe schafft hier zum Beispiel der Einsatz von modsecurity unter
+Apache2 (https://doxsec.wordpress.com/2017/06/11/using-modsecurity-web-application-firewall-to-prevent-sql-injection-and-xss-using-blocking-rules/)
 
 Upgrade auf v3.5.4