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:
For the composite actions such as start/claim now a Composite command is used that guarantees that both actions are executed in a single transaction. Here is the fix in 6.2.x: http://github.com/droolsjbpm/jbpm-console-ng/commit/e6831a81c
Created attachment 990417 [details] reproducer-bpm-suite-6.1.0.ER4.zip
Verified in BPM Suite 6.1.0.ER4. I have attached new reproducer for BPM Suite 6.1.0.ER4 (reproducer-bpm-suite-6.1.0.ER4.zip) as there were several changes necessary: 1.) module structure of jbpm services has changed in 6.1 2.) group 'admin' was changed to 'broker' and then I could see my testing task, because according to Mauricio, 'admin' tasks are filtered in 6.1: (11:55:54 AM) salaboy: avoid using admin if you are not testing anything related with admin things (11:56:29 AM) salaboy: well that could be because the task is being filtered to not show anythign related with admin groups or users 3.) jar containing UserGroupInfoProducer needs to be placed into business-central.war/WEB-INF/lib directory due to new fat war packaging, not into modules. After that I could see the difference, in case of problematic 'root' user the task returned to 'Ready' status instead of wrong 'Reserved' one.
Employee 'msalatin' has left the company.