feat: extract Optimize v3.7.0 docs for Components & Self Managed sect…

…ions (#1408)

* optimize(3.7.0): init

* optimize(3.7.0): move components docs into 3.7.0 instance

* optimize(3.7.0): update sidebars and optimize_sidebars for moved docs

* optimize(3.7.0): update markdown links from optimize to docs

* optimize(3.7.0): move self-managed docs into 3.7.0 instance

* optimize(3.7.0): update sidebars and optimize_sidebars for self-managed docs

* optimize(3.7.0): revert some cross-instance markdown links now that I also moved self-managed

* optimize(3.7.0): update markdown links from optimize to docs (self-managed)

* optimize(3.7.0): update markdown links from docs to optimize

* optimize(3.7.0): revert a couple accidental removals

* optimize(3.7.0): redirect rules for docs that have been moved

.prettierignore

@@ -24,3 +24,4 @@ versioned_docs/version-1.0
 versioned_docs/version-1.1
 versioned_docs/version-1.2
 versioned_docs/version-1.3
+optimize_versioned_docs/version-3.7.0

versioned_docs/version-1.3/components/optimize/userguide/additional-features/alerts.md → optimize_versioned_docs/version-3.7.0/components/userguide/additional-features/alerts.md

@@ -5,7 +5,7 @@ description: Get a notification as soon as your system is behaving in an unexpec
 ---
 
 :::note
-You must configure the email service to receive notifications. See the [technical guide](../../../../self-managed/optimize-deployment/setup/installation.md) for which properties need to be defined.
+You must configure the email service to receive notifications. See the [technical guide](../../../self-managed/optimize-deployment/setup/installation.md) for which properties need to be defined.
 :::
 
 Optimize's alerting functionality can be used to notify you when your report hits a predefined critical value. You can create alerts for any number reports that exist within a collection. Inside the collection, navigate to the **Alerts** tab to create and view all alerts defined for reports in this collection. You can manage an alert by moving the mouse over the alert entry and clicking the **Edit** or **Delete** buttons in the context menu on the right side of the page.
@@ -33,4 +33,4 @@ You also enabled reminder notifications to be sent each hour. Here's what that w
 
 ## Send alerts to external systems
 
-It's possible to configure Optimize to send alerts to an external system when needed. For details on how to configure and add target systems, visit the [technical guide](../../../../self-managed/optimize-deployment/setup/installation.md). Once at least one target system is configured, alerts will have a new input option to select one of the configured systems.
+It's possible to configure Optimize to send alerts to an external system when needed. For details on how to configure and add target systems, visit the [technical guide](../../../self-managed/optimize-deployment/setup/installation.md). Once at least one target system is configured, alerts will have a new input option to select one of the configured systems.

versioned_docs/version-1.3/components/optimize/userguide/additional-features/event-based-processes.md → optimize_versioned_docs/version-3.7.0/components/userguide/additional-features/event-based-processes.md

@@ -15,21 +15,21 @@ Once the event-based process feature is correctly configured, you will see a new
 :::note
 When Camunda activity events are used in event-based processes, Camunda admin authorizations are not inherited for the event-based process. The authorization to use an event-based process is solely managed via the access management of event-based processes when [publishing an event-based process](#publishing-an-event-based-process) or at any time via the [edit access option](#event-based-process-list---edit-access) in the event-based process list.
 
-Visit our [technical guide](../../../../self-managed/optimize-deployment/setup/installation.md) on authorization management and event-based processes for the reasoning behind this behavior.
+Visit our [technical guide](../../../self-managed/optimize-deployment/setup/installation.md) on authorization management and event-based processes for the reasoning behind this behavior.
 :::
 
 ## Set up
 
-You need to set up the event-based processes feature to make use of this feature. See the [technical guide](../../../../self-managed/optimize-deployment/setup/installation.md) for more information.
+You need to set up the event-based processes feature to make use of this feature. See the [technical guide](../../../self-managed/optimize-deployment/setup/installation.md) for more information.
 
 ## Event-based process list
 
 All currently available event-based processes are listed under the main navigation item **Event-based processes**. From there, it is possible to see their state, which can be one of the following:
 
-* `Unmapped` - The process model is created, but no single event is mapped to a flow node.
-* `Mapped` - The process model contains at least one mapping of an event to a flow node.
-* `Published` - The event-based process is published and can be used in reports by users that are authorized to access it.
-* `Unpublished Changes` - The process model contains changes that are not reflected in the currently published state of the event-based process; it needs to get republished manually.
+- `Unmapped` - The process model is created, but no single event is mapped to a flow node.
+- `Mapped` - The process model contains at least one mapping of an event to a flow node.
+- `Published` - The event-based process is published and can be used in reports by users that are authorized to access it.
+- `Unpublished Changes` - The process model contains changes that are not reflected in the currently published state of the event-based process; it needs to get republished manually.
 
 ![Process List](./img/processList.png)
 
@@ -73,12 +73,12 @@ Finally, you can create an event-based process by uploading a `.bpmn` file direc
 
 The edit mode allows you to build and map your event-based process. Using this mode, you can perform all kinds of operations, such as:
 
-* Rename the process.
-* Model the process using the integrated BPMN modeler.
-* Map your diagram nodes to an event from the event table.
-* Edit event sources for the events to display in the event table.
-* Save the current state with your applied changes.
-* Cancel changes you already applied to the process.
+- Rename the process.
+- Model the process using the integrated BPMN modeler.
+- Map your diagram nodes to an event from the event table.
+- Edit event sources for the events to display in the event table.
+- Save the current state with your applied changes.
+- Cancel changes you already applied to the process.
 
 ### Modeling
 
@@ -104,23 +104,23 @@ Defining the `group` property when ingesting the events will allow selecting eve
 
 These are events generated from an existing Camunda BPMN process. Only processes for which Optimize has imported at least one event will be visible for selection. This means the process has to have at least one instance and Optimize has to have been configured to import data from that process.
 
-See the [technical guide](../../../../self-managed/optimize-deployment/setup/installation.md) for more information on how this is configured.
+See the [technical guide](../../../self-managed/optimize-deployment/setup/installation.md) for more information on how this is configured.
 
 To add such events, provide the following details:
 
-* The target process definition that you would like to generate the events from
+- The target process definition that you would like to generate the events from
 
-* The trace ID location: A trace ID uniquely identifies a process instance across system boundaries. One example would be an invoice number for an invoice handling process. For a Camunda process, it is possible to select a trace ID that exists either in a variable or in the process business key.
+- The trace ID location: A trace ID uniquely identifies a process instance across system boundaries. One example would be an invoice number for an invoice handling process. For a Camunda process, it is possible to select a trace ID that exists either in a variable or in the process business key.
 
-* Which events to display in the table:
+- Which events to display in the table:
 
 Adding events for every flow node might not be necessary for the event-based process. Therefore, we provide the ability to only add the events that are necessary. There are three options available:
 
-  * Process start and end: This will add only two events in the table, one event is triggered when the process starts and one when it ends.
+- Process start and end: This will add only two events in the table, one event is triggered when the process starts and one when it ends.
 
-  * Start and end flow node events: The number of events added to the table will depend on how many start and end events are in the process. For example, if there is one start event and two end events, three events will be added.
+- Start and end flow node events: The number of events added to the table will depend on how many start and end events are in the process. For example, if there is one start event and two end events, three events will be added.
 
-  * Start and end flow node events: This option will add events for every flow node in the process.
+- Start and end flow node events: This option will add events for every flow node in the process.
 
 Once this information is defined and the sources are added, the events will appear in the table as shown below.
 
@@ -130,17 +130,18 @@ Once this information is defined and the sources are added, the events will appe
 
 Each event in the table will have the following properties:
 
-* Mapped as (start/end): Defines whether the event indicates start of BPMN node or the end of it.
+- Mapped as (start/end): Defines whether the event indicates start of BPMN node or the end of it.
 
-* Event name
+- Event name
 
-* Group
-  * For external events, this corresponds to the group of the ingested event.
-  * For Camunda process events, this corresponds to the name of the process definition.
+- Group
 
-* Source: External system or Camunda process event.
+  - For external events, this corresponds to the group of the ingested event.
+  - For Camunda process events, this corresponds to the name of the process definition.
 
-* Count: How many times this event was triggered. See [additional notes](#event-counts) for more information.
+- Source: External system or Camunda process event.
+
+- Count: How many times this event was triggered. See [additional notes](#event-counts) for more information.
 
 To assist during event mapping, the events table offers suggestions of potential events to be mapped based on the selected node. This is indicated by a blue strap near the suggested event. The event suggestion only works when adding all external events as a source with no Camunda events.
 
@@ -154,7 +155,7 @@ To start mapping, take the following steps:
 2. To link the selected node to an event, enable the checkbox of that event from the table. Afterwards, a checkmark sign will be shown on top of the node to indicate that the event has been mapped successfully.
 
 :::note
-  Not all BPMN nodes can be mapped. Only events and activities can be mapped to events.
+Not all BPMN nodes can be mapped. Only events and activities can be mapped to events.
 :::
 
 Once all the necessary nodes are mapped, you can save your diagram to go the view mode.
@@ -222,26 +223,26 @@ In some scenarios, reports created using event-based processes might not show al
 
 To avoid this, we encourage you to avoid including the following elements when modelling your event-based processes:
 
-* Inclusive gateways: These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
+- Inclusive gateways: These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
 
 ![Inclusive Gateway](./img/inclusive_gateway.png)
 
-* Complex gateways: These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
+- Complex gateways: These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
 
 ![Complex Gateway](./img/complex_gateway.png)
 
-* Mixed gateway directions: Mixed gateways are gateways which have no clear direction, instead being a combination of opening and closing gateways. These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
+- Mixed gateway directions: Mixed gateways are gateways which have no clear direction, instead being a combination of opening and closing gateways. These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
 
 ![Mixed Direction Gateway](./img/mixed_direction_gateway.png)
 
-* Chained gateways: A chained gateway is one that occurs as part of a sequence of consecutive gateways. These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
+- Chained gateways: A chained gateway is one that occurs as part of a sequence of consecutive gateways. These may be modeled in an event-based process diagram. However, visual data flow will be interrupted on reports such as heatmaps.
 
 ![Chained Gateway](./img/chained_gateway.png)
 
 ### Event counts
 
 Event counts in the table may not match the values you expected. There are three possible explanations for this:
 
-* If you have enabled history cleanup, the counts will still include events from process instances that have since been cleaned up.
-* For events from Camunda processes, the count value represents the number of times that event has occurred across all versions and tenants of that process, regardless of how the event source is configured.
-* The counts for external events will still include ingested events that have since been deleted using the [event inspection feature](#deleting-ingested-events).
+- If you have enabled history cleanup, the counts will still include events from process instances that have since been cleaned up.
+- For events from Camunda processes, the count value represents the number of times that event has occurred across all versions and tenants of that process, regardless of how the event source is configured.
+- The counts for external events will still include ingested events that have since been deleted using the [event inspection feature](#deleting-ingested-events).

versioned_docs/version-1.3/components/optimize/userguide/additional-features/filters.md → optimize_versioned_docs/version-3.7.0/components/userguide/additional-features/filters.md

@@ -108,7 +108,7 @@ Take the following example: Today is Wednesday, March 11. If you set a process i
 Take the following example: today is March 28. If you set a process instance start date filter to the last three days, you get all process instances that were started from March 26 to March 28. A day passes, and we now have March 29. Applying the same filter now filters the process instances which were started from March 27 to March 29.
 
 - If you do not want the filter to be completely dynamic, you can also select `Between`, `Before`, or `After`.
- - The `Between` option only considers process instances started or ended within a fixed date range (e.g. filter all process instances between 2018-01-01 and 2018-01-26). This range is fixed and does not change.  
+- The `Between` option only considers process instances started or ended within a fixed date range (e.g. filter all process instances between 2018-01-01 and 2018-01-26). This range is fixed and does not change.
 - In the same way, you can select `After` or `Before` options to only consider process instances that started or ended after/before a fixed date.
 
 The start and the end date filters are independent and can be applied to a report simultaneously. However, be aware that each of these filters can only exist once. If, for example, you define a new start date filter when another one already exists, the second one will replace the first one.
@@ -235,7 +235,7 @@ Similar to the other variables, there are two input switches that allow you to e
 
 ### List variable filters
 
-To filter based on the value of a [list variable](../../../../../self-managed/optimize-deployment/setup/object-variables#list-variables), the applied filter will depend on the primitive type of items within the list. For example, you will be creating a numeric variable filter for a variable which is a list of numbers, a string variable filter for a list of strings, and so on. It is important to note here that filters are applied on each individual item within the list variable and not the list itself.
+To filter based on the value of a [list variable](../../../self-managed/optimize-deployment/setup/object-variables.md#list-variables), the applied filter will depend on the primitive type of items within the list. For example, you will be creating a numeric variable filter for a variable which is a list of numbers, a string variable filter for a list of strings, and so on. It is important to note here that filters are applied on each individual item within the list variable and not the list itself.
 
 For example, an "is" filter on a list of string values filters for those instances where any individual list item is equal to the given term. For example, instances whose list variable "contains" the selected value.
 
@@ -255,21 +255,21 @@ As shown in the example, it is possible to select one or more assignees or even
 
 This filter has different behavior depending on where it was [defined](#filter-behavior):
 
-- As a `Flow Node data filter` applied on a user task report: This filter only includes user task instances that satisfy *all* assignee/candidateGroup filters defined in the report at once. Mutually exclusive filters like having both an inclusive and an exclusive filter on the same assignee do not yield any results in user task reports.
+- As a `Flow Node data filter` applied on a user task report: This filter only includes user task instances that satisfy _all_ assignee/candidateGroup filters defined in the report at once. Mutually exclusive filters like having both an inclusive and an exclusive filter on the same assignee do not yield any results in user task reports.
 
-- As an `instance filter`: This filter includes all process instances where *at least one* user task satisfies one particular assignee/candidateGroup criterion. This means multiple mutually exclusive assignee/candidateGroup filter entries might still yield results for these reports (e.g. if the process definition contains multiple user tasks).
+- As an `instance filter`: This filter includes all process instances where _at least one_ user task satisfies one particular assignee/candidateGroup criterion. This means multiple mutually exclusive assignee/candidateGroup filter entries might still yield results for these reports (e.g. if the process definition contains multiple user tasks).
 
 ## Incident filter
 
 This filter has a different behavior depending on where it was [defined](#filter-behavior):
 
 - As an `instance filter`: This filter will retrieve only those process instances that contain open, resolved, or no incidents (depending on your selection). Here are some examples where this filter can be useful:
 
-    - Creating reports that contain no incidents since the instances that have incidents have very long durations and are influencing your data.
+  - Creating reports that contain no incidents since the instances that have incidents have very long durations and are influencing your data.
 
-    - To monitor all the instances from multiple engines that have open incidents.
+  - To monitor all the instances from multiple engines that have open incidents.
 
-    On the other hand, this filter is not useful for counting the number of incidents because instances with an open or resolved instance filter might still contain instances from the other type.
+  On the other hand, this filter is not useful for counting the number of incidents because instances with an open or resolved instance filter might still contain instances from the other type.
 
 - As a `Flow Node data filter`: This filter will additionally filter the instance incident states to only include incidents of the same type (open or resolved). As an example, This filter can be used to count the number of open or resolved incidents since it considers the incidents of that type exclusively. This filter is currently only useful if you are in an incident view report.