names for personal task list and takable task list

[tom.baeyens]

hi,

i want decide on the names for the 2 specific task lists in the console:

1) the list of tasks directly assigned to the authenticated user. aka personal task list, aka assigned task list

2) the list of tasks that the currently authenticated user can take. aka group task list, aka takable task list

whatever name we choose, we must use the same in the api, impl as in the console.

suggestions ?

[kukeltje]

Personally, I prefer personal and group. Sounds more 'natural' since for me a task that has just a group 'assigned' to it is already assigned. but just on a group level. Could be because in the real life situations I encountered, tasks could be 'assigned' to different groups during a process because e.g. it should go to a different department.

[brittm]

We often use the terminology "user" queue and "group" queue to distinguish. This seems to be terminology that our users understand. "Personal" would work just as well as "user".

[camunda]

My vote: "personal" and "group" task list.

Takable is understable for me, aber not really the easiest word to find ;-)

[heiko.braun]

regarding "takeable":

currently takable means that a user participates as 'candidate'.
but it's an implementation detail of the findTakable() and take() methods. IMO you should come up with something else that's more close to the participation model and is reflected properly in the TaskService interface. I.e:

findTaskByParticipation(Identity, Participation.CANDIDATE)

Not only would it shed some light on what's actually going on,
but it also open the door for other participation types.

[tom.baeyens]

ok. let's rename to getPersonalTaskList and getGroupTaskList

Heiko, can you elaborate on what exactly you mean ?

getPersonalTaskList is the task list for which the currently authenticated user is the assignee.

getGroupTaskList is the list of tasks that the current authenticated user can take. Taking the task is allowed if

the task has no assignee
AND (
 the user is a candidate for that task
 OR
 user is a member of a group which is a candidate for that task
 )

to what extend does this match or violate what you expect ?

i am in favour os putting both lists in one view/screen: the personal task list on top and the group task list below. And then maybe later add a separate view/screen to query tasks based on filter criteria.