Tasks therefore firstly get assigned to an organisation and then to an individual within it.
Be careful with the terminology here. A "candiate-group" statement doesn't "assign" the task. It merely states what groups (or group members actually) are elected for an assignment. Even when the task finally get's assigned to a user, the "candidate-group" remains an orthogonal entity.
Again, please use the userforum for this. Has nothing to do with the development ON jBPM, merely development WITH jBPM.
How are task lists impacted when we are using swimlane candidate-groups which both a user and a group of users [organisation] can belong?
I was wondering about "candidate-group" and "candidate-user" as well.
Not sure if that fits your question, but I'll throw it in anyway:
- Should those two statement be mutual exclusive an a single task activity?
- Why a "candidate-user" in the first place?
- Does a set of "candidate-users" form an artificial "candidate-group"?
- How does re-assignment fit into the picture? Who is privileged to re-assign a task? Does the user need to be in one of the "candidate-groups"?
IMO it's a design discussion topic.
the contents of the 2 lists is clear:
The user task list shows all the tasks that are directly assigned to the currently authenticated user.
The group task list shows all the tasks that don't have an assignee and for which the currently authenticated user is a candidate.
the only discussion that is left open is the name of those 2 lists: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155305