1 of 1 people found this helpful
I have spent some time evaluating jBPM5 and I would say that, in general, jBPM5 mostly allows the application to determine how users are associated with groups.
Of course, I don't know how you are planning to use jBPM5, if you are planning to run everything in the Console and not implement your own application, you may not find my advice so useful and will have to rely on somebody else's response.
Although the ActorId parameter in a Human Task can be "hard-coded" to specify a particular individual (although I suppose "actor" does not necessarily have to indicate a specific individual in real life) in most practical situations, if you are going to use the ActorId parameter it will be determined at run time and this will be indicated in your model via some sort of expression, typically an expression that references a process variable. If ActorId is specified and GroupId is not specified, then the task will be immediately assigned to that actor (but not if GroupId is also specified, from what I have personally observed).
So in this situation, as I see it, it would be the responsibility of the application to determine whether an actor has the necessary group membership. If you want to specify the actor for a particular task when creating a new process, or at some later point during the lifecycle of that process, you should be able to determine this based on your own requirements. So if the actor for "Task One" is has to satisfy some criteria (such as membership in a group) then if you want to designate them when creating the process, you first perform some test on your side that determines this. If this will be determined downstream, then it gets more complicated. Probably the actor will be determined as a side effect of completing an upstream task, captured as a task variable, then mapped back to the process instance. So when completing this upstream task, the logic used to identify this actor will ensure this actor is in the appropriate group along with any other criteria needed to designate a specific actor.
An important mechanism whereby the application determines group membership is when implementing org.jbpm.task.service.UserGroupCallback, particular the getGroupsForUser method. You should be able to find some discussion of this in the User Manual.
I have avoided going into too much detail on this, but I hope this brings you somewhat closer to the answer you need, cheers!
Thanks for your response JE.
I am implementing my own application to work with JBPM. It seems that from your answer, and from my knowledge so far on JBPM, that user-group assignment restrictions are outside the scope of JBPM.
In your experience, have you used any sort of Rules (Drools) to determine if a User is authorised to perform a task? If so, is there any simple example you can point me to?
That would be very helpful.
Also, I will have a look at the UserGroupCallback class.
Quick answer which is all I have time for at the moment:
a.) I haven't tried specifying such a rule in Drools however that makes perfect sense. It's a matter of having access to the data Drools needs to resolve your rule.
b.) I don't know of any example of this.
c.) In my case, actors would be determined by looking at LDAP data, specifically roles and geographic location or membership in some local group. I think the actual logic on the application side would be simple so I don't know whether I'd see a need to develop a Drools rule.
Thanks for all your help JE.