Bug 1125079

Created attachment 922808 [details]
reproducer including: 1) mvn project "01135268"; 2) custom eap module; 3) process def. for BPMS

Description of problem:

When a group member claims a taks in business-central, TaskServiceEntryPointImpl#claimBatch() is executed:

    public void claimBatch(List<Long> taskIds, String user) {
        for (Long taskId : taskIds) {
            taskService.claim(taskId, user);
            taskService.start(taskId, user);
        }
    }

After taskService.claim(taskId, user), the task status changes to "Reserved".
And if an exception is thrown in taskService.start(taskId, user) , the task status will not be changed back to "Ready" (it will stay "Reserved")

In my testing scenario, the exception thrown from taskService.start() is: org.jbpm.services.task.exception.PermissionDeniedException



How reproducible:

Always


Steps to Reproduce:
There should be other more simple / general ways to reproduce the issue, but I'll just use the reproducer from the customer support case. 

In this case a custom UserGroupCallback is implemented. The custom UserGroupCallback returns inconsistent user/group data intentionally (gives 'false' when checking user existance, but gives some group ids when retrieve user group info.)

So the user can see the task and can click the 'claim' button, but while executing taskService.start(), it gives this error:

15:55:58,398 WARN  [org.jbpm.services.task.persistence.TaskTransactionInterceptor] (http-localhost.localdomain/127.0.0.1:8080-2) Could not commit session: org.jbpm.services.task.exception.PermissionDeniedException: User 'null' does not have permissions to execution operation 'Start' on task id 2


Testing steps:

1) install BPMS 6.0.2 and add 2 users: [bpmsAdmin] and [root], add both of them with [admin] role.

2) package the mvn project 01135268 in the zip attachment, and make it a module for eap (`custom` folder is packaged already, just drop this into eap's module folder)

3) change business-central.war/WEB-INF/beans.xml as below to enable the custom usergroup call back

-------------------
<beans xmlns="http://java.sun.com/xml/ns/javaee";; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";;
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd">;;

  <alternatives>
<class>com.test.services.producer.CustomTestUserGroupInfoProducer</class>
  </alternatives>
  <interceptors>
    <class>org.uberfire.security.server.authz.cdi.RolesInterceptor</class>
    <class>org.uberfire.security.server.authz.cdi.TraitInterceptor</class>
  </interceptors>
</beans>
-------------------

4) add this dependency in business-central.war/WEB-INF/jboss-deployment-structure.xml:

<module name="custom.test.usergroupinfo" export="true" services="import" meta-inf="import"/>


5) start BPMS and login as bpmsAdmin, add a process def. include a simple user task, set the [Groups] to "admin" for this task (check rewards.bpmn2 file in zip)

6) start a process instance, and go to "Tasks - Task List", should be able to see it

7) Now, claim it with "bpmsAdmin" user, it is claimed correctly and others cannot see it in group list

But if use "root" user to claim it here, following log will be printed out and the task goes to "Reserved" status.


15:55:58,398 WARN  [org.jbpm.services.task.persistence.TaskTransactionInterceptor] (http-localhost.localdomain/127.0.0.1:8080-2) Could not commit session: org.jbpm.services.task.exception.PermissionDeniedException: User 'null' does not have permissions to execution operation 'Start' on task id 2
	at org.jbpm.services.task.internals.lifecycle.MVELLifeCycleManager.evalCommand(MVELLifeCycleManager.java:98) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.internals.lifecycle.MVELLifeCycleManager.taskOperation(MVELLifeCycleManager.java:322) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.identity.UserGroupLifeCycleManagerDecorator.taskOperation(UserGroupLifeCycleManagerDecorator.java:46) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.impl.TaskInstanceServiceImpl.start(TaskInstanceServiceImpl.java:204) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.StartTaskCommand.execute(StartTaskCommand.java:48) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.StartTaskCommand.execute(StartTaskCommand.java:30) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.CompositeCommand.execute(CompositeCommand.java:38) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.TaskCommandExecutorImpl$SelfExecutionCommandService.execute(TaskCommandExecutorImpl.java:65) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:41) [drools-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.persistence.TaskTransactionInterceptor.execute(TaskTransactionInterceptor.java:54) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.commands.TaskCommandExecutorImpl.execute(TaskCommandExecutorImpl.java:40) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.services.task.impl.command.CommandBasedTaskService.start(CommandBasedTaskService.java:245) [jbpm-human-task-core-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.console.ng.ht.backend.server.TaskServiceEntryPointImpl.claimBatch(TaskServiceEntryPointImpl.java:512) [jbpm-console-ng-human-tasks-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at org.jbpm.console.ng.ht.backend.server.TaskServiceEntryPointImpl$Proxy$_$$_WeldClientProxy.claimBatch(TaskServiceEntryPointImpl$Proxy$_$$_WeldClientProxy.java) [jbpm-console-ng-human-tasks-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
......





Actual results:

Task status is set to "Reserved" after failure.


Expected results:

If there is any error / exception during the executiion of TaskServiceEntryPointImpl#claimBatch(), the task status should rollback to the initial status (same as before we execute this method)


Additional info: