nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

History variables in parallel executions

walterjs

I've noticed that when history is on full and a parallel task completes with variables associated with it:

taskService.complete(taskId, vars);‍

the variables are not saved against the activityInstanceId or the execution it is running in, but only against the process instance.

I've created a JIRA for this http://jira.codehaus.org/browse/ACT-815 with a test case that shows what is happening.

Find more posts tagged with

Comments

jbarrez

Thanx for the jira. I'll look into it.

vicziani

Any progress? I think, it is a serious bug. I would like to show the value of the variable connected to the activity. There is a Jira issue (created on 16/May/11) and test case too.
Could you suggest any workaround?

frederikherema1

Workaround:

- Use taskService.setvariablesLocal() or delegateTask.setVariableLocal() to ensure task-id is used in history, instead of passing the when calling "completeTask"
- THe variables passed in taskService.complete are written to the process-instance indeed, this is normal behavior. By default (not using setVariableLocal) If there is no variable present for a given key in the task/execution, the parent is checked. If the value key is present on the parent it's set there. This goes on until the root of the execution-tree. If process-instance is reached and no child-executions contained the variable already, it's set on the process-instance.

vicziani

It works like a charm! Thank you!

Workaround:

- Use taskService.setvariablesLocal() or delegateTask.setVariableLocal() to ensure task-id is used in history, instead of passing the when calling "completeTask"
- THe variables passed in taskService.complete are written to the process-instance indeed, this is normal behavior. By default (not using setVariableLocal) If there is no variable present for a given key in the task/execution, the parent is checked. If the value key is present on the parent it's set there. This goes on until the root of the execution-tree. If process-instance is reached and no child-executions contained the variable already, it's set on the process-instance.