Tasks will not be updated on the task list of the organizer if delegate updates the tasks
Closed, ResolvedPublic


Task will not be updated on the task list of the organizer if delegate updates the tasks. Doesn´t matter if the task was completely or only partially done.

  • User1 creates two Tasks "Fortschritt 100%" and "Fortschritt 50%" and assigns both tasks to User2.

  • User2 accepts both tasks.
  • User1 receives two emails that the tasks have been accepted by User2.
  • User2 finish task "Fortschritt 100%" and set the status to 100%.

Task is moved automatically to the closed task list of User2.

  • User1 receives an email that the Task "Fortschritt 100% was updated, "Status Done".

BUT: In the task list of User1, the task "Fortschritt 100%" is still active and has still 0%.

  • User2 is working on task "Fortschritt 50%" and set the status to 50%. If status field is set to "---" no email is sent to the organizer, if status field is set to "in Bearbeitung" an email is sent to the organizer.

BUT: User1 will not see the progress on his task.

  • If the organizer change the progress, the delegates are informed that the task was updated and have to accept the task again.

The organizer of the task will be automatically informed if the task was set to 100% or if the delegate changes the status in status field. This behaviour seems to be ok. In both cases the tasks on the task list of the organizer are neither updated nor closed if the task was partially or completely done. This behaviour is incorrect.

For the organizer it is even not visible if the delegate accepted the task. Behind the delegate name the status is still "?"


Ticket Type

Event Timeline

Let's substitute the use of the word "delegate" here, for the "assignee" -- to avoid confusion with the actual delegation scenario involving a secretary, or indeed the delegation scenario in iTip.

The problems seems with the updating of the organizer's copy. It is expected that only those changes by the assignee that trigger a notification update the organizer's copy (i.e. acceptance, declination, status change).

Ok, there's a couple of issues here described, but first... Let's agree that (while we do not support counter proposals) when an attendee changes a task's status the iTip REPLY is send to the organizer. When the REPLY is "merged" only an attendee status should be updated, NOT the completion status. Think about a task with two attendees (assignees).

Maybe there's a place for improvement, e.g. optionally change task status to completed if there's only one attendee and this attendee send REPLY with partstat=COMPLETED. For cases without wallace we could display an additional button/checkbox in UI to update task status with participant status.

Now let's consider bugs:

  • 4th bullet point: generated iTip is correct, but for some reason updated object contains <partstat> set to NEEDS-ACTION. Looks like COMPLETED parts stat is not correctly handled here, this is however a local copy, so should not cause any later issues here. (Bug#1).
  • 5th bullet point: On the organizer side wallace handles above REPLY correctly setting partstat in the object to COMPLETED, but this is displayed as unknown (NEEDS-ACTION?) icon in the task dialog. (Bug#2).
  • 5th bullet point: If we disable wallace invitations handling, the organizer will see the iTip message and will be able to "Update participant status". This however, generated invalid NEED-ACTION partstat value as in Bug#1. (Bug#3).
  • 7th bullet point: I can't reproduce neither with enabled and disabled wallace.

Fixed Bug#1, Bug#2, Bug#3 described in my previous comment.

Some of the behavior that seems to be requested (albeit not explicitly) leans toward workflow management more so than it is squarly within the realm of simple task management.

The endless types of tasks may all have separate, distinct requirements of their own;

  • "get me a coffee" task only needs 1 attendee to accept and report completed, regardless of how many you invite,
  • "perform complex fu as group" tasks may require assignees to cumulatively report progress / completion rather than on an individual basis,
  • "everyone do fu" tasks may require each attendee to perform an action individually, while the organizer themselves cannot also be attendees, and therefore cannot go ahead and complete his/her own task ahead of all others.
  • etc., etc.

In other words, closing the organizer's copy of the task as completed, just because all assignees have reported the tasks to be completed is a behavior pattern that is applicable only to a limited number of types of tasks.

That is not to be said that this particular pattern cannot be made the default pattern for the simple task management provided in Kolab, but that's an enhancement and will require evaluation beyond the scope of this ticket.

machniak closed this task as Resolved.Aug 9 2016, 11:35 AM
machniak claimed this task.