camunda / camunda-bpm-platform

Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Quarkus, Spring, Spring Boot, CDI.
https://camunda.com/
Apache License 2.0
4.13k stars 1.56k forks source link

Start date filter for modify operation #4586

Closed venetrius closed 1 month ago

venetrius commented 2 months ago

User Story (Required on creation)

When filtering for process instances to modify in cockpit modify workflow I want to be able to apply a filter to the startDate of the process instance.

Functional Requirements (Required before implementation)

API:

Breakdown

Add IncidentIdIn filter to HistoricProcessInstanceQuery

Java API
SQL

incidentId is available in ACT_HI_INCIDENT the logic to join ACT_HI_INCIDENT is already present in HistoricProcessInstanceQuery and only needed to be updated with a check on the new field.

Code changes in `HistoricProcessInstance.xml` ```diff - 0))"> ... + + ${queryType} INC.ID_ IN + + #{incidentIdItem} + + ```

Swap processInstanceQuery to historicProcessInstanceQuery in modify operation

Update instancesList.js to use historicProcessInstanceQuery
Code changes ```diff InstancesList.prototype.updatePage = function(resetSelection) { ... -self.delegate.api - .resource('process-instance') - .list(params, function(err, result) { - self.delegate.instances = result; - self.delegate.applySelection(); - checkLoading(); - }); - -self.delegate.api - .resource('process-instance') - .count(params, function(err, result) { - self.delegate.instancesCount = result.count; - checkLoading(); - }); + const HistoryResource = self.delegate.api.resource('history'); +HistoryResource.processInstance(params, function(err, result) { + self.delegate.instances = result; + self.delegate.applySelection(); + checkLoading(); +}); +HistoryResource.processInstanceCount(params, function(err, result) { + self.delegate.instancesCount = result.count; + checkLoading(); +}); ```
Filter out finished instances

In instancesList.js add unfinished = true filter to all modify instances query to only show runtime instance and not finished or canceled ones

Update keys in filter configuration

Keys, values and available operators are defined in instances-search-config.json Keys are the filter names that are sent in a request, values are the labels that are visible for a customer.

Example: Config for filtering by subprocess instance id ```js { "id": { "key": "subProcessInstanceId", "value": "PLGN_MOD_SEARCH_SUB_ID" }, "operators": [ { "key": "eq", "value": "=" } ] }, ``` What the users sees when filtering by subprocess instance id SubId

Update the key for the filters and leave the values unchanged so the users don't have to re-learn the filter names.

Update local storage key used to save modify queries

Update the storage-group in modification-confirmation-dialog.html from "'PI'" to "'PIM'" (Process Instance Modification)

image

Limitations of Scope

Hints

Links

epic

### Breakdown
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4587
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4588
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4589
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4618
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4632
- [ ] https://github.com/camunda/camunda-bpm-platform/issues/4620
### Pull Requests

Dev2QA handover

tasso94 commented 2 months ago

Decisions

Due to replacing the runtime with the history query, some behavioral changes occur:

  1. Tokens sitting on an asyncBefore/asyncAfter task won't yield process instances with the activityIdIn filter since no history has been produced yet.
    • The user filtering always races against the job executor, leading to potentially frequent state state changes that impact what the query returns. Usually, the job executor is faster than a user can filter. The main use case of this filter is for real wait states like user tasks, external tasks, timers, etc., and not for transaction boundaries. We have already accepted this limitation for the standalone batch operation page. This feature alignes the behavior between token move and the standalone batch operation page.
  2. When doing compensation, previously, it was possible to retrieve process instances with the activityIdIn filter on the subprocess "activity". This is an edge case and is not possible for all sub-process setups. We were only able to reproduce this for the compensation scenario. We accept this behavior change. The alternative way to do this, which we think is more common for most of the users, is to filter for concrete flow nodes and not for subprocesses. image
venetrius commented 1 month ago

Dev2QA:

@gbetances089 There are 3 things to pay extra attention:

gbetances089 commented 1 month ago

Tested on the 7.22.0 release candidate final