KOE broken for recurring to-do items

[itserv]

Hi there!

I have a very weird situation here, and I’m very sure KOE is broken when it comes to recurring tasks. This prevents further production use of KOE with z-push.

Setup:
KC 8.5.9.0
z-push 2.4.2
KOE 1.6.282
WebApp 3.4.15.1513
Outlook 365

Problem:
I have recurring items in my to-do list. However, depending on the device I look at, the due-date (Fälligkeit) is different on verious views.

My Outlook uses z-push. There is a weekly recurring item, which has been created and marked as done for at least one time. Then, I fired up another Outlook and synched to that account.

Now,

• Outlook says, an item is due 04.06.2018
• webapp says, the same item is due 28.05.2018 (overdue)
• the newly synch’ed Outlook, the item is due 28.05.2018 (overdue)

Accessing the same account using the Zarafa Windows client, it says the item is 28.05.2018 (overdue).

To me, this looks as recurring events are processed locally by outlook, but the change is not propagated back to KC, so other devices do not get the update. Or something like that.

How to reproduce:

1. create a task, making it daily recurring and set the start date back to the past (for example, to 28.05.2018), no end date
2. mark this item as done. Outlook will mark the item of 28.05.2018 as done, and create a new one for 29.05.2018
3. access the account with webapp. You will see two items: the one for 28.05.2018, not marked as done, and a new one for 29.05.2018
4. sync another Outlook to this account. It will show the same two items with the same dates.

This proves it’s broken

Now, to have some fun. On the newly synched Outlook, mark the recurring item of 28.05.2018 as done. Outlook will crash.

Next, using WebApp, mark the item of 28.05.2018 as done. You will get an error message: “You don’t have enough rights”. Howver, the item is then shown as done, but it becomes duplicated. You can see the duplicates on all Outlooks, and the same in Webapp.

The current Kopano Groupware Features states that recurring tasks are not supported by webapp or deskapp. My experience is: these tools break recurring items. And they do not work over ActiveSync on multiple devices.

To me, this is a HUGE PROBLEM, as this behavior requires me to fall back to the Zarafa Client, and do not work with recurring tasks on any ActiveSync device.

Would you please confirm this problem?

Thank you!

[Manfred]

Hi Peter,

could you provide WBXML log for that? WBXML is really enough, you don’t have to set it to WBXMLSTACK.

Manfred

[itserv]

I will gather the data this evening.

[itserv]

OK, I have done multiple steps to show you what’s going on

Step 1

1. I create a daily recurring item in Outlook, starting at 28.05.2018
2. I mark it done

The data can be found at https://www.dropbox.com/s/kxnwwmygdtdnguh/pbauer-Step1.log?dl=0

Outlook shows:

WebApp shows:

As you see, WebApp does not show the task of 28.05. as done, neither shows 29.05. as recurring.

Step 2
In WebApp, I mark the Task of 29.08. as done.

The data can be found at https://www.dropbox.com/s/0dfn7xslhs2m26h/pbauer-Step2.log?dl=0

Outlook shows:

WebApp shows:

The recurring task is not forwarded to 30.05., and Outlook has lost its entry of 28th, whereas in WebApp it’s still there.

Step 3
I freshly sync in a new Outlook.

Sync data for the new device can be found at https://www.dropbox.com/s/2rih0yjucz59tq3/pbauer-Step3.log?dl=0

Here is what it shows:

You can see the original recurring task at 28th, with 29th done. This view matches what WebApp shows.

[Manfred]

Hi Peter,

as webapp and deskapp doesn’t support the recurring tasks, saving such a task will remove the recurrence information from it. Your Outlook screenshot in step 2 shows a regular task icon instead of a recurring one.

Let’s assume that the initial recurring task created in Outlook has the id 47 (the id is actually 4653ce44e8e74770981f433d22ebe0a0473300000000, but 47 is the unique part of it) and due date 28th. You then mark the task as complete. Outlook sends the modify request moving the due date to the next day (29th). From the initial task Outlook also generates a new completed task with the id 48 (4653ce44e8e74770981f433d22ebe0a0483300000000) and due date 28th. This tasks also contains the recurrence information.

I don’t know why webapp doesn’t show the one task as completed in step 1. Have you checked how it looks on another client, e.g. mobile device or another Outlook configured to connect to that account? It also looks like PHP-MAPI mixed up the due date (it’s possible that the timezone information wasn’t handled correctly - in the log of step 2 and 3 the UTC* date fields are at 00:00 instead of 22:00 like in step 1).

In step 2 you modify the task with the id 48 which was actually has due date on the 28th, but after saving it in webapp the due date moves to the 29th, that’s why there are two tasks with due date on the 29th.

Step 3 just syncs both tasks to Outlook again with task 47 containing the recurrence information and task 48 not.

For now I can only suggest not to edit (that’s also includes marking a task as complete) recurring tasks with a client which doesn’t support it. However it doesn’t mean that there aren’t any bugs in Z-Push or PHP-MAPI recurrence library which Z-Push uses.

Manfred

[itserv]

Manfred,

thank you one more time for your detailled analysis.

OK, I can understand that this example primary suffers from a lack of support for recurring events in Webapp (which is, by the way, very sad). I will try to reproduce another problem with recurring events. I’ll explain it when I was able to collect the log files.

An I will try to learn to understand the WBXML structure for myself. Maybe I can find and understand the source of the problem myself.

Question: when it comes to recurring events, who’s responsible for handling the event? Is it the client which has do mark the current event as done, then calculate the next due date and recreate a new task, or is it the server which has to react on the fact a recurring item is marked as done?

[Manfred]

Hi Peter,

in the ActiveSync realm it depends on the client if the server has to regenerate a new task or not. The client sends Regenerate tag with the value of either 0 (do not regenerate, the client will do it itself) or 1 (the server has to generate the new task). Outlook e.g. does it itself as you can see in the logs in step 1.

Manfred