Changing candidate group with DynamicBpmnService

Flowable Engine
1

Hello,
Using the following execlistener, I try to dynamically change the candidate group:

public void notify(DelegateExecution execution) {
String targetGroup = (String) execution.getVariable(“newgroup”);
DynamicBpmnService dynamicBpmnService =
org.flowable.engine.ProcessEngines.getDefaultProcessEngine().getDynamicBpmnService();
ObjectNode infoNode = dynamicBpmnService.changeUserTaskCandidateGroup(“newassigneegrouptask”, targetGroup, true);
dynamicBpmnService.saveProcessDefinitionInfo(execution.getProcessDefinitionId(), infoNode);

the activity id of the target activity is verified to be “newassigneegrouptask”, and the targetGroup is correctly set to “sales”. However, when reaching the target activity, and then signing in as a member of the group
“sales” there is no task available. I have tried to attach the execution listener at various places before the
target activity. I would much appreciate some suggestions here.

2

That should work as you state there, we’ve got a unit test that test it in that way (https://github.com/flowable/flowable-engine/blob/f98a8c381eac0fec8517492c51769f4143db6c91/modules/flowable-engine/src/test/java/org/flowable/engine/test/bpmn/usertask/DynamicUserTaskTest.java#L171).

Where is this execution listener invoked? Could it be the task identity links (which store the groups) already have been created and persisted and thus cannot be changed anymore? The changeUserTaskCandidateGroup will change the process definition model, but not the data that’s already persisted.

3

Thank you for the swift answer.

I looked into the unit test and it seems that the change must be done before instantiating the process. That explains why it doesn’t work in my test case, which is a simple linear sequence flow with three tasks: usertask1, scripttask2, usertask3. usertask 1 sets the value of the new group, scripttask2 is mainly there to verify the change. I have tried to attach the execlistnener at various places, sucha as the end of usertask1, and in the usertask2. The usertask3 was then supposed to have a new candidate group. But clearly, I try to apply the change in one and the same process instance, so that seems to be the problem.

This might be an over-simplified test case for what I actually intend to achieve. The intended functionality is to define a callable subprocess having a dummy candidate group, and then to supply the actual candidate group as an in-parameter to the call. Ideally this should be done (upon the end event ?) of the call activity itself. If not possible, I could live with doing it in a script task in front of the call activity. In both of these cases, a new subprocess is instantiated, so maybe that resolves the problem? I will try a more elaborate test case more in line with the intended use.

4

Update: Trying to put the task whose candidate group is to be changed in a subprocess to be
run by means of a call activity did not make the problem dissipate. So the problem of setting the candidate users/groups in a form in a main process and then use this info to adjust the access rights in a task in a subprocess remains (to me).

5

Or is the described use case such that a TaskListener should be used?
I do not find the javadoc for org.flowable.task.service.delegate.DelegateTask though.

6

From what I understood from your message. I suppose you want to change a candidate group of an already running process instance (or more specifically a task in an already running process).

You can do that with the TaskListener and with the DelegateTask you can add / remove Candidate groups.

You don’t need the DynamicBpmnService to achieve this.

7

Thank you for your suggestion! I still have problems, though.

I installed a task listener script and added a new candidate group. The tasklistener is set to be fired upon the create event. This had no effect, logging in as a user which is member of the new group still did not see the task.
Doing the same thing, but instead of adding a new candidate group, adding a new candidate user, I got a strange behaviour, when logging in as the new user, the browser window started an infinite refresh loop.

8

I have problems with the dynamic assignment of users and groups to a running process by means of a task listener. The following minimal test case has been executed on two different machines with the same result. We have an App with a model with one user activity. The process is instantiated by ‘admin’ who is the only candidate user. The one and only User activity has a script task listener attached, which executes this (and a log message):

task.addCandidateUser("xsales").

There exists a user with id ‘xsales’. When starting the process as ‘admin’ the log message is displayed, so the listener script is registered. When claiming the task as ‘admin’, a form is presented, and the process is terminated upon submit. If instead signing out and signing in as ‘xsales’ and trying to claim the task by trying to open the app, the gui enters an infinite “refresh window”-loop, making it inaccessible for user input. One has to kill the tab or window. Doing the same ting but with a group, that is:
task.addCandidateGroup("sales")

(where sales is an existing group, with one user, ‘xsales’) nothing at all happens, even though the listener message is displayed on the console. Without jumping to conclusions, this looks like a bug? Exactly the same happens when using a java TaskListener instead of a script task listener.

9

Hi,

Can you share the BPMN XML snippet for this user task showing the configuration of the task listener?

Best regards,

Tijs

10

Ok, thanks!

Somehow, the preview gets messed up, if there is a problem with this, maybe I can send the
snippet via mail

<userTask id="adjustedcands" name="AdjustedCands" flowable:candidateUsers="admin" flowable:formKey="T1F">
  <extensionElements>
    <flowable:taskListener event="create" class="org.flowable.engine.impl.bpmn.listener.ScriptTaskListener">
      <flowable:field name="language">
        <flowable:string><![CDATA[groovy]]></flowable:string>
      </flowable:field>
      <flowable:field name="script">
        <flowable:string><![CDATA[println "=== TaskListener, event: ${task.getEventName()}"

task.addCandidateUser(“xsales”)]]></flowable:string>
</flowable:field>
</flowable:taskListener>

11

Thanks, that looks alright. In your previous post you say the following:

If instead signing out and signing in as ‘xsales’ and trying to claim the task by trying to open the app, the gui enters an infinite “refresh window”-loop, making it inaccessible for user input.

Which call is performed to claim the task? Are you using the Flowable Task application? If so, do you see any javascript errors when opening the Javascript console in your browser?

Best regards,

Tijs

12

I use the Flowable Task Application. The error occurs when having signed in as the (presumably) new user, and clicking on the application. There are javascript errors, but difficult to capture because of the looping which seems to refresh the console. But at least I got this:

angular.js:9827 GET http://localhost:18080/flowable-task/workflow/i18n/en-US.json 404 ()

Maybe the looping occurs when not being able to load a resource?

Thanks,
rol

13

No, it’s trying to get the translation file for your locale, but that isn’t there so it does a fallback to the default.
I see you have a form key of T1F, does that correspond with a form definition key you have deployed with this process definition? If you can let us know how we can reproduce this step by step and with your example app shared that would help to understand the cause of this.

Best regards,

Tijs

14

Yes, the form is there. When admin claims the task instead of the ‘xsales’ user, the form is displayed, and the process terminates normally upon submit.

Is it convenient that I share the app as a .zip and send it via mail?

Thanks,
rol

15

Ok thanks, yes I’ll sent you a private message with my email address.

Best regards,

Tijs