chore(user-engine): mention mandatory TTL (#1580)

* document mandatory TTL
* adjust paragraph names
* adjust references
* add link to custom history level
* new pages:
  * History configuration
  * User operation log
  * History cleanup
  * Custom implementation
  * index page will be loaded when link to the old page can't be resolved

camunda/camunda-bpm-platform#4031

content/reference/bpmn20/custom-extensions/extension-attributes.md

@@ -1302,7 +1302,7 @@ The following attributes are extension attributes for the `camunda` namespace `h
   <tr>
     <th>Description</th>
     <td>
-      The attribute specifies the history time to live (in days) for the process definition. It is used within <a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a>.
+      The attribute specifies the history time to live (in days) for the process definition. It is used within <a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a>.
     </td>
   </tr>
   <tr>

content/reference/cmmn11/custom-extensions/camunda-attributes.md

@@ -471,7 +471,7 @@ The following attributes are extension attributes for the `camunda` namespace `h
   <tr>
     <th>Description</th>
     <td>
-      The attribute specifies the history time to live (in days) for the case definition. It is used within <a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a>.
+      The attribute specifies the history time to live (in days) for the case definition. It is used within <a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a>.
     </td>
   </tr>
   <tr>

content/reference/deployment-descriptors/tags/process-engine.md

@@ -471,7 +471,7 @@ The following is a list with the most commonly used process engine configuration
     <td><code>history</code></td>
     <td>String</td>
     <td>
-        Sets the <a href="{{< ref "/user-guide/process-engine/history.md#choose-a-history-level">}}">level of the process engine history</a>.
+        Sets the <a href="{{< ref "/user-guide/process-engine/history/history-configuration.md#choose-a-history-level">}}">level of the process engine history</a>.
       <p>
         <strong>Values:</strong> <code>none</code>, <code>activity</code>, <code>audit</code>, <code>full</code>.
       </p>
@@ -497,7 +497,7 @@ The following is a list with the most commonly used process engine configuration
     <td><code>historyRemovalTimeStrategy</code></td>
     <td>String</td>
     <td>
-      Controls if and when the <a href="{{< ref "/user-guide/process-engine/history.md#removal-time">}}">removal time</a> of an historic instance is set.
+      Controls if and when the <a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md#instance-removal-time">}}">removal time</a> of an historic instance is set.
       The default value is <code>end</code>.<br>
       Please also see the <a href="{{< ref "/reference/deployment-descriptors/tags/process-engine.md#historyCleanupStrategy">}}"><code>historyCleanupStrategy</code></a>
       configuration parameter.<br><br>
@@ -1115,7 +1115,7 @@ The following is a list with the most commonly used process engine configuration
     <td><code>historyCleanupStrategy</code></td>
     <td>String</td>
     <td>
-      Controls which <a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a> strategy is used.
+      Controls which <a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a> strategy is used.
       The default value is <code>removalTimeBased</code>.<br>
       Please also see the <a href="{{< ref "/reference/deployment-descriptors/tags/process-engine.md#historyRemovalTimeStrategy">}}"><code>historyRemovalTimeStrategy</code></a> configuration parameter.<br><br>
       <strong>Values:</strong> <code>removalTimeBased</code>, <code>endTimeBased</code>.
@@ -1129,27 +1129,27 @@ The following is a list with the most commonly used process engine configuration
   <tr>
     <td><code>historyCleanupBatchWindowStartTime</code></td>
     <td>String</td>
-    <td><a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a> batch window start time in the format <code>HH:mmZ</code> (Z is for RFC 822 time zone) or <code>HH:mm</code>. E.g., <code>20:00+0100</code> or <code>20:00</code>. In case of <code>null</code>, no batch window is considered to be configured
+    <td><a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a> batch window start time in the format <code>HH:mmZ</code> (Z is for RFC 822 time zone) or <code>HH:mm</code>. E.g., <code>20:00+0100</code> or <code>20:00</code>. In case of <code>null</code>, no batch window is considered to be configured
     and history cleanup can only be called manually.</td>
   </tr>
   <tr>
     <td><code>historyCleanupBatchWindowEndTime</code></td>
     <td>String</td>
-    <td><a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a> batch window end time in the format <code>HH:mmZ</code> (Z is for RFC 822 time zone) or <code>HH:mm</code>. E.g., <code>23:00-0300</code> or <code>23:00</code>. In case <code>batchWindowEndTime</code> exceeds <code>batchWindowStartTime</code> it is considered
+    <td><a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a> batch window end time in the format <code>HH:mmZ</code> (Z is for RFC 822 time zone) or <code>HH:mm</code>. E.g., <code>23:00-0300</code> or <code>23:00</code>. In case <code>batchWindowEndTime</code> exceeds <code>batchWindowStartTime</code> it is considered
     to be on the same date (e.g., cleanup runs each day between 20:00 and 23:00). Otherwise it is considered to be on the next calendar day (e.g., cleanup starts each
     day at 20:00 and finishes the next day at 01:00). Default value is `00:00`.</td>
   </tr>
   <tr>
     <td><code>mondayHistoryCleanupBatchWindowStartTime</code></td>
     <td>String</td>
-    <td><a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a> batch window start time for Mondays. Requires the same format as <code>historyCleanupBatchWindowStartTime</code>.
+    <td><a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a> batch window start time for Mondays. Requires the same format as <code>historyCleanupBatchWindowStartTime</code>.
     In case it is not configured, batch window configured with <code>historyCleanupBatchWindowStartTime</code> and <code>historyCleanupBatchWindowEndTime</code> will be used for this day of week.
     </td>
   </tr>
   <tr>
     <td><code>mondayHistoryCleanupBatchWindowEndTime</code></td>
     <td>String</td>
-    <td><a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a> batch window end time for Mondays. Requires the same format and follows the same logic
+    <td><a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a> batch window end time for Mondays. Requires the same format and follows the same logic
     as <code>historyCleanupBatchWindowEndTime</code>.
     </td>
   </tr>
@@ -1254,7 +1254,7 @@ The following is a list with the most commonly used process engine configuration
     <td>Boolean</td>
     <td>
         Configures whether the engine participates in history cleanup or not. The default value is <code>true</code>.
-        For more details, please see <a href="{{<ref "/user-guide/process-engine/history.md#cleanup-execution-participation-per-node" >}}">Cleanup Execution Participation per Node</a>
+        For more details, please see <a href="{{<ref "/user-guide/process-engine/history/history-configuration.md#cleanup-execution-participation-per-node" >}}">Cleanup Execution Participation per Node</a>
         in the User Guide.
     </td>
   </tr>

content/reference/dmn/custom-extensions/camunda-attributes.md

@@ -20,7 +20,7 @@ The following attributes are extension attributes for the `camunda` namespace `h
   <tr>
     <th>Description</th>
     <td>
-      The attribute specifies the history time to live (in days) for the decision definition. It is used within <a href="{{< ref "/user-guide/process-engine/history.md#history-cleanup">}}">History cleanup</a>.
+      The attribute specifies the history time to live (in days) for the decision definition. It is used within <a href="{{< ref "/user-guide/process-engine/history/history-cleanup.md">}}">History cleanup</a>.
     </td>
   </tr>
   <tr>

content/update/minor/710-to-711/_index.md

@@ -231,7 +231,7 @@ In order to read (or delete) entries that are not related to process definitions
 
 * permission `READ` (or `DELETE`) on resource `UserOperationLogCategory` with the resource id set to the respective category of the entry or `*`
 
-An overview of the operation logs and their categories can be found at [User Operation Log]({{< ref "/user-guide/process-engine/history.md#glossary-of-operations-logged-in-the-user-operation-log" >}}).
+An overview of the operation logs and their categories can be found at [User Operation Log]({{< ref "/user-guide/process-engine/history/user-operation-log.md#glossary-of-operations-logged-in-the-user-operation-log" >}}).
 Authorization management is detailed in [Authorization Service]({{< ref "/user-guide/process-engine/authorization-service.md" >}}).
 
 # Custom WritableIdentityProvider

content/update/minor/714-to-715/_index.md

@@ -194,7 +194,7 @@ You can read more about the metrics in our [Metrics Guide]({{< ref "/user-guide/
 
 Since the metrics data accumulated over time can become substantial, it is possible to
 
-* configure a history time live for the task metrics data so it is picked up by [History Cleanup]({{< ref "/user-guide/process-engine/history.md#task-metrics" >}})
+* configure a history time live for the task metrics data so it is picked up by [History Cleanup]({{< ref "/user-guide/process-engine/history/history-configuration.md#task-metrics" >}})
 * manually clean up the task metrics data through API
 
 Manually deleting task metrics data can be done via {{< restref page="deleteTaskMetrics" text="REST API" tag="Metrics" >}} or Java API by using the `deleteTaskMetrics` method provided by the `ManagementService`.

content/update/minor/719-to-720/_index.md

@@ -85,7 +85,7 @@ their historic data grow over time and remain uncleaned due to this configuratio
 we decided to make the historyTimeToLive mandatory for new deployments or redeployments.
 
 At the same time, we acknowledge there might be use cases (e.g. when there are no history events fired at all, 
-see [history level]({{< ref "/user-guide/process-engine/history.md#set-the-history-level" >}}) configuration) 
+see [history level]({{< ref "/user-guide/process-engine/history/history-configuration.md#set-the-history-level" >}}) configuration) 
 where our users might favour to keep the legacy behaviour despite our recommendation. 
 If that is the case, you can always turn off the feature by setting the feature flag `enforceHistoryTimeToLive` to `false`. 
 For more information, checkout the new parameter description under <a href="{{< ref "/reference/deployment-descriptors/tags/process-engine#configuration-properties" >}}">Configuration Properties</a>.

content/update/minor/73-to-74/_index.md

@@ -125,7 +125,7 @@ This is already the default for Camunda 7 versions after and including 7.3.3 and
 
 ### User Operation Log
 
-The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history.md#user-operation-log" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
+The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history/user-operation-log.md" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
 
 Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API `TaskService#getTaskEvents`. If you rely on this API method, the previous behavior can be restored by setting the flag `restrictUserOperationLogToAuthenticatedUsers` to `false`.
 

content/update/minor/73-to-74/glassfish.md

@@ -95,7 +95,7 @@ This is already the default for Camunda 7 versions after and including 7.3.3 and
 
 ## User Operation Log
 
-The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history.md#user-operation-log" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
+The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history/user-operation-log.md" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
 
 Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API `TaskService#getTaskEvents`. If you rely on this API method, the previous behavior can be restored by setting the flag `restrictUserOperationLogToAuthenticatedUsers` to `false`.
 

content/update/minor/73-to-74/jboss.md

@@ -105,7 +105,7 @@ This is already the default for Camunda 7 versions after and including 7.3.3 and
 
 ## User Operation Log
 
-The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history.md#user-operation-log" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
+The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history/user-operation-log.md" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
 
 Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API `TaskService#getTaskEvents`. If you rely on this API method, the previous behavior can be restored by setting the flag `restrictUserOperationLogToAuthenticatedUsers` to `false`.
 

content/update/minor/73-to-74/tomcat.md

@@ -102,7 +102,7 @@ This is already the default for Camunda 7 versions after and including 7.3.3 and
 
 ## User Operation Log
 
-The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history.md#user-operation-log" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
+The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history/user-operation-log.md" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
 
 Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API `TaskService#getTaskEvents`. If you rely on this API method, the previous behavior can be restored by setting the flag `restrictUserOperationLogToAuthenticatedUsers` to `false`.
 

content/update/minor/73-to-74/was.md

@@ -97,7 +97,7 @@ This is already the default for Camunda 7 versions after and including 7.3.3 and
 
 ## User Operation Log
 
-The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history.md#user-operation-log" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
+The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history/user-operation-log.md" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
 
 Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API `TaskService#getTaskEvents`. If you rely on this API method, the previous behavior can be restored by setting the flag `restrictUserOperationLogToAuthenticatedUsers` to `false`.
 

content/update/minor/73-to-74/wls.md

@@ -87,7 +87,7 @@ This is already the default for Camunda 7 versions after and including 7.3.3 and
 
 ## User Operation Log
 
-The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history.md#user-operation-log" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
+The behavior of the [user operation log]({{< ref "/user-guide/process-engine/history/user-operation-log.md" >}}) has changed, so that operations are only logged if they are performed in the context of a logged in user. This behavior can be toggled in the process engine configuration using the property `restrictUserOperationLogToAuthenticatedUsers` (default `true`). To restore the engine's prior behavior, i.e., to write log entries regardless of user context, set the flag to `false`.
 
 Furthermore, with 7.4 task events are only logged when they occur in the context of a logged in user. Task events are accessible via the deprecated API `TaskService#getTaskEvents`. If you rely on this API method, the previous behavior can be restored by setting the flag `restrictUserOperationLogToAuthenticatedUsers` to `false`.
 

content/update/minor/76-to-77/_index.md

@@ -30,7 +30,7 @@ Noteworthy new Features and Changes in 7.7:
 * [Deploy Processes, Decisions and Cases from Cockpit]({{< ref "/webapps/cockpit/deployment-view.md#create-deployment" >}})
 * [New Batch API for modification of multiple process instances]({{< ref "/user-guide/process-engine/process-instance-modification.md#modification-of-multiple-process-instances" >}})
 * [Process instance restart + Batch API]({{< ref "/user-guide/process-engine/process-instance-restart.md" >}})
-* [Automatic cleanup of historic data based on TTL]({{< ref "/user-guide/process-engine/history.md#history-cleanup" >}})
+* [Automatic cleanup of historic data based on TTL]({{< ref "/user-guide/process-engine/history/history-cleanup.md" >}})
 * [New cryptographic hash function with salt] ({{< ref "/user-guide/process-engine/password-hashing.md" >}})
 * {{< restref text="External tasks history" tag="Historic-External-Task-Log" >}}