[migration]
### Migration of Scheduler Jobs
Every Scheduler task since version 12 will be migrated to the Task Planner in the setup when updating a system that used the previous Scheduler. 

Migrating tasks from the Scheduler to the Task Planner

* Make sure that the plugin **Task Planner - Render Reports** is activated
* Make sure **all** tasks of **all** users are deleted from the Task Planner. Migration only occurs if the Task Planner is empty.
* Restart your server. In the initialization phase it will now migrate the tasks silently.
* If it does not migrate the Scheduler tasks to the Task Planner please check the log files and send it to our support.

#### Migration issues
When tasks are migrated from Scheduler to Task Planner, some minor issues may arise, since many things have been streamlined and simplified. See the following hints.

#### Reports
* The setting `as file:` was removed, which gave each generated report a different name. Now the name of the generated file(s) come from the title configured in the report template (*.rpt). However, the *File System* Action has an option *File Name Format* which allows you to construct a unique name.

#### Action settings
* For `Save (on servers file system)` the settings *Attach date* and *Attach time* was combined into the option *File Name Format*.
* For `Send via Email`, the CC and BCC options were removed, and values from CC are added as normal receivers. The options *Put reports in a zip file*, *Attach date* and *Attach time* were removed.
* For `Print (at server-known printer)` the option *Count of Copies* was removed, it always prints once. Other even older options like *orientation* and *quality* which were only available via Java API were also removed.

#### Time settings
There are some rare combinations of settings which were possible with the old Scheduler but are no longer possible with the Task Planner. It is possible some of the more exotic settings will get a slightly different behavior in the Task Planner.

* Daily execution with a `DayStepSize` greater than 1, which means execute every `N` days. In the scheduler this adds `N` days from the start date for each next execution. After conversion to Task Planner this always starts at the 1st of month and then adds `N` days for each next execution. If the `DayStepSize` is 7 then it will convert to a weekly interval.
* Weekly execution with a `WeekStepSize` greater than 1, which means every `N` weeks. If it is 2 then a `Two Weeks` interval will be used. Other values are not supported in the Task Planner and when converting this it will set the `WeekStepSize` to 1.
* Monthly execution with a `MonthStepSize` greater than 1, which means every `N` months. In the scheduler this adds `N` months to the start date for each next execution. This can only be represented with a Cron Trigger. The Cron starts at a given month and then adds `N` months for the next execution. When converting such tasks it will determine the start-month automatically in order to match the correct interval. This only works if the `MonthStepSize` is 2, 3, 4, 6 or 12. For other values it will be every `N` months, but the execution month will likely be wrong.
* Yearly execution with a `YearStepSize` greater than 1, which means every `N` years. This is not supported in the Task Planner and when converting this it will set the `YearStepSize` to 1. 
* Delete this task after Execution: This feature is not available in the Task Planner.
* Multiple executions on same day: one Time or Cron-Trigger does not support this, but you can add multiple triggers to the same task. When those tasks are migrated it will create many triggers automatically.
* End execution after `N` executions or after a given Date: this feature is not available in the Task Planner. When converting expired tasks they will be deactivated.

#### Custom Actions
Old custom actions will not work after migrating to the Task Planner. Those actions must be replaced with custom *Jobs* and/or *Actions*. See the programming samples for how to implement your own Job or Action.

#### Dynamic Properties
Old dynamic properties classes will not work after migration to Task Planner. If you loaded your dynamic values from a Database then you can probably replace your custom dynamic properties with a *Database Series*. For other cases it should be replaced with a custom Series implementation. See the programming samples for how to implement your own Series type.

#### Task owner
In Task Planner, each task always must have an owner, so a task belongs to a user. Migrated tasks will have `Scheduler` as owner. Because certain triggers, jobs and result handlers require certain permissions the artificial user `Scheduler` gets some permissions automatically if you have System Permissions enabled. If you remove the permissions it can happen that tasks can no longer be executed.

If you want to move the tasks to another user then you must duplicate a task and then delete the old one. The new task will belong to the currently logged in user.

### The Repository: permissions and ownership
Due to the new user the reporting server is running with there may be permission problems when accessing the Repository browser. You should look up the path of your repository in the Configuration Manager and check the permissions of this path in a console program on the server.

It is important for the reporting server that its user has read+write permissions to every file and additional execute permissions for directories. The owner of each file and directory should be the user the reporting server is executed with.

You can find out the respective user using `ps aux | grep java`.

A server restart is required after these changes were made.

[migration:de]
### Migration von Scheduler-Jobs
Alle Scheduler-Aufgaben seit Version 12 werden bei der Aktualisierung eines Systems, das den vorherigen Scheduler verwendet hat, in den Task-Planer im Setup migriert.

Migration von Aufgaben aus dem Scheduler in den Task Planner

* Stellen Sie sicher, dass das Plugin **Task Planner - Render Reports** aktiviert ist
* Stellen Sie sicher, dass **alle** Aufgaben von **allen** Benutzern aus dem Task Planner gelöscht werden. Die Migration erfolgt nur, wenn der Aufgabenplaner leer ist.
* Starten Sie Ihren Server neu. In der Initialisierungsphase wird er nun die Aufgaben stillschweigend migrieren.
* Wenn die Aufgaben nicht in den Task-Planer migriert werden, überprüfen Sie bitte die Log-Dateien und senden Sie diese an unseren Support.

#### Probleme bei der Migration
Bei der Migration von Aufgaben aus dem Scheduler in den Task Planner können einige kleinere Probleme auftreten, da viele Dinge gestrafft und vereinfacht worden sind. Siehe die folgenden Hinweise.

#### Berichte
* Die Einstellung `als Datei:`, die jedem generierten Bericht einen anderen Namen gab, wurde entfernt. Der Name der erzeugten Datei(en) ergibt sich nun aus dem in der Berichtsvorlage konfigurierten Titel (*.rpt). Die Aktion *Dateisystem* verfügt jedoch über eine Option *Dateinamensformat*, mit der Sie einen eindeutigen Namen konstruieren können.

#### Aktionseinstellungen
* Für `Speichern (auf Server-Dateisystem)` wurden die Einstellungen *Anbringungsdatum* und *Anbringungszeit* in der Option *Dateinamenformat* zusammengefasst.
* Bei `Versenden per E-Mail` wurden die Optionen CC und BCC entfernt, und die Werte von CC werden als normale Empfänger hinzugefügt. Die Optionen *Put reports in a zip file*, *Attach date* und *Attach time* wurden entfernt.
* Für `Drucken (auf Server-bekanntem Drucker)` wurde die Option *Anzahl der Kopien* entfernt, es wird immer nur einmal gedruckt. Andere noch ältere Optionen wie *Orientierung* und *Qualität*, die nur über die Java-API verfügbar waren, wurden ebenfalls entfernt.

#### Zeiteinstellungen
Es gibt einige seltene Kombinationen von Einstellungen, die mit dem alten Scheduler möglich waren, aber mit dem Task-Planer nicht mehr möglich sind. Es ist möglich, dass einige der exotischeren Einstellungen im Task-Planer ein etwas anderes Verhalten zeigen.

* Tägliche Ausführung mit einer `DayStepSize` größer als 1, d.h. Ausführung alle `N` Tage. Im Planer werden dann `N` Tage ab dem Startdatum für die nächste Ausführung addiert. Nach der Konvertierung in Task Planner beginnt dies immer am 1. des Monats und addiert dann `N` Tage für jede nächste Ausführung. Wenn die `DayStepSize` 7 ist, wird es in ein wöchentliches Intervall umgewandelt.
* Wöchentliche Ausführung mit einer `WeekStepSize` größer als 1, d.h. alle `N` Wochen. Bei einem Wert von 2 wird ein Intervall von `Zwei Wochen` verwendet. Andere Werte werden vom Aufgabenplaner nicht unterstützt und bei der Konvertierung wird die "Wochenschrittweite" auf 1 gesetzt.
* Monatliche Ausführung mit einer `MonthStepSize` größer als 1, d.h. alle `N` Monate. Im Scheduler werden dann `N` Monate zum Startdatum für die nächste Ausführung hinzugefügt. Dies kann nur mit einem Cron-Trigger dargestellt werden. Der Cron startet zu einem bestimmten Monat und fügt dann `N` Monate für die nächste Ausführung hinzu. Bei der Konvertierung solcher Aufgaben wird der Startmonat automatisch bestimmt, um das richtige Intervall zu finden. Dies funktioniert nur, wenn die `MonthStepSize` 2, 3, 4, 6 oder 12 ist. Für andere Werte wird es alle `N` Monate sein, aber der Ausführungsmonat wird wahrscheinlich falsch sein.
* Jährliche Ausführung mit einer `YearStepSize` größer als 1, was alle `N` Jahre bedeutet. Dies wird vom Aufgabenplaner nicht unterstützt und bei der Konvertierung wird `YearStepSize` auf 1 gesetzt.
* Diese Aufgabe nach der Ausführung löschen: Diese Funktion ist im Aufgabenplaner nicht verfügbar.
* Mehrere Ausführungen am gleichen Tag: Ein Zeit- oder Cron-Trigger unterstützt dies nicht, aber Sie können mehrere Trigger zur gleichen Aufgabe hinzufügen. Wenn diese Aufgaben migriert werden, werden automatisch mehrere Auslöser erstellt.
* Beenden der Ausführung nach `N` Ausführungen oder nach einem bestimmten Datum: Diese Funktion ist im Aufgabenplaner nicht verfügbar. Wenn Sie abgelaufene Aufgaben konvertieren, werden diese deaktiviert.

#### Benutzerdefinierte Aktionen
Alte benutzerdefinierte Aktionen werden nach der Migration in den Task-Planer nicht mehr funktionieren. Diese Aktionen müssen durch benutzerdefinierte *Aufträge* und/oder *Aktionen* ersetzt werden. Sehen Sie sich die Programmierbeispiele an, um zu erfahren, wie Sie Ihren eigenen Job oder Ihre eigene Aktion implementieren können.

#### Dynamische Eigenschaften
Alte dynamische Eigenschaftsklassen werden nach der Migration auf Task Planner nicht mehr funktionieren. Wenn Sie Ihre dynamischen Werte aus einer Datenbank geladen haben, können Sie Ihre benutzerdefinierten dynamischen Eigenschaften wahrscheinlich durch eine *Datenbankreihe* ersetzen. In anderen Fällen sollten Sie sie durch eine benutzerdefinierte Serien-Implementierung ersetzen. In den Programmierbeispielen erfahren Sie, wie Sie Ihren eigenen Serientyp implementieren können.

#### Aufgabenbesitzer
In Task Planner muss jede Aufgabe immer einen Besitzer haben, d.h. eine Aufgabe gehört zu einem Benutzer. Migrierte Aufgaben haben `Scheduler` als Besitzer. Da bestimmte Auslöser, Jobs und Ergebnis-Handler bestimmte Berechtigungen benötigen, erhält der künstliche Benutzer `Scheduler` automatisch einige Berechtigungen, wenn Sie Systemberechtigungen aktiviert haben. Wenn Sie die Berechtigungen entfernen, kann es passieren, dass Aufgaben nicht mehr ausgeführt werden können.

Wenn Sie die Aufgaben auf einen anderen Benutzer verschieben wollen, müssen Sie eine Aufgabe duplizieren und dann die alte Aufgabe löschen. Die neue Aufgabe gehört dann dem aktuell angemeldeten Benutzer.

### Das Repository: Berechtigungen und Eigentum
Aufgrund des neuen Benutzers, unter dem der Berichtsserver läuft, kann es beim Zugriff auf den Repository-Browser zu Berechtigungsproblemen kommen. Sie sollten den Pfad Ihres Repositorys im Konfigurationsmanager nachschlagen und die Berechtigungen für diesen Pfad in einem Konsolenprogramm auf dem Server überprüfen.

Für den Berichtsserver ist es wichtig, dass sein Benutzer Lese- und Schreibrechte für jede Datei und zusätzliche Ausführungsrechte für Verzeichnisse hat. Der Eigentümer jeder Datei und jedes Verzeichnisses sollte der Benutzer sein, unter dem der Berichtsserver ausgeführt wird.

Sie können den entsprechenden Benutzer mit `ps aux | grep java` herausfinden.

Ein Neustart des Servers ist erforderlich, nachdem diese Änderungen vorgenommen wurden.
