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.
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".
My vote: "personal" and "group" task list.
Takable is understable for me, aber not really the easiest word to find ;-)
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:
Not only would it shed some light on what's actually going on,
but it also open the door for other participation types.
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.