Inofficial fix for basic recurring tasks

This is an inofficial fix for problems with z-push 2.4.5 and recurring to-dos. I am not related to the Kopano company in any way, so this is community code. Use at your own risk - I accept no responsibilities for whatever happens on your site. It has been tested only with 9folders Nine, Version 4.4.1d on Android 5.1.1. The modified code works for me. It does not mean, it will work for you or solve your problem.

The issues addressed are:

  • when an recurring to-do is marked complete, the icon is not checked as done
  • when an recurring to-do is marked complete, the icon is not a simple to-do, but a recurring to do
  • problems with duplication of to-dos
  • Outlook 2016 sets a weird finished date when a recurring to-do was created in Outlook, than marked as done on Nine,
    then the newly created recurring to-do is marked as done in Outlook
  • Outlook 365 crashes when a recurring to-do was created in Outlook, than marked as done on Nine, then the newly created recurring to-do is marked as done in Outlook
  • error messag ein z-push-error.log:
09/11/2018 14:24:24 [12411] [WARN] [someuser] /usr/share/z-push/backend/kopano/mapi/class.taskrecurrence.php:103 Undefined offset: -2138701566 (8)
09/11/2018 14:24:24 [12411] [WARN] [someuser] /usr/share/z-push/backend/kopano/mapi/class.taskrecurrence.php:104 Invalid argument supplied for foreach() (2)

Unsolved problems:

  • any complex recurrency involving a start or end date. Only simple “do this every week, infinite” or “do that everyday, 15 times” seem to work.

Problems discovered and how I worked around them:

  • the original source code creates repetition information for completed tasks if the AS client sends those. This seems to be stupid to be done by the client, so I changed the code to add repetition information only on non-completed tasks. This fixed the icon issues.
  • to fix the problem with the error message, I make sure a structure has a valid information. Currently, the structure $task->recurrence->start is unset, probably due to another problem. As a result, the repetition info can’t be saved in the MAPI backend, which breaks leads to the message in the error log and breaks OL2016 and OL356.

The file patched is z-push/backend/kopano/mapiprovider.php. My modified version can be downloaded at

The diff of my modification against the original 2.4.5 file is like this:

root@netprobe:/usr/share/z-push/backend/kopano# diff mapiprovider.php mapiprovider.php.orig 
<             if (!($task->complete)) { // recurrency is only processed when the task is not completed, otherwise OL gets confused
< 		// Set PR_ICON_INDEX to 1281 to show correct icon in category view
< 	        $props[$taskprops["icon"]] = 1281;
>             // Set PR_ICON_INDEX to 1281 to show correct icon in category view
>             $props[$taskprops["icon"]] = 1281;
<             if (isset($task->recurrence->start)) { // for some reason, $task->recurrence->start is not always (aka never) set
< 		$recur["start"] = $task->recurrence->start;
< 	    } else {
<             	$recur["start"] = $task->duedate; 
< 	    }
>             $recur["start"] = $task->recurrence->start;
<             $recurrence->setRecurrence($recur);	
< 		}
>             $recurrence->setRecurrence($recur);

Maybe this helps somebody to get at least simple recurrent tasks to work.

I’m happy to hear from Kopano what they think about these fixes, especially the fact I simply do not create recurrence data if a task that is completed.

I would’nt wonder if Kopano warns about using my code. So, again: use on your own risk.

@Kopano: if you have problems with having me parked my version of the file on Dropbox, please tell me. I will remove it immediately if you want me to. I clearly accept every right you have on the source code.

Hi itserv,

while your fix solves the issues you’re having with recurring tasks in Nine in Outlook now, I doubt it will work properly once webapp implements recurring tasks support because you don’t save recurrence data when a task is completed.

if (isset($task->recurrence->start)) { // for some reason, $task->recurrence->start is not always (aka never) set

According to the ActiveSync documentation start is a required child element of the recurrence element: It also explains how to handle it if is not set. Simply setting it to due date is wrong. If I’m not completely mistaken Start is the same for all occurrences of a recurrence which allows to attribute an occurrence to the specific recurring task.



I’m happily looking forward for a WebApp that supports recurrence elements. Maybe, this improves the z-push backend and makes recurring tasks working there, too. I’m happy on every update which makes my hack needless.

Of course I disconnected my z-push installation from updates through the repository, as an update would remove my modification. And I have disabled automatic updates for 9folders Nine App. Because I know THESE combination of versions works now, and future updates might no longer work. Bad luck for me, but I need working recurring tasks now and not at some time in the future.

Finally, I’ll have a test server for whenever a new version of z-push comes along, I will test any new versions coming from you if they make my modifications obsolete. I would be happy if they will become obsolete. And every new version will be tested by me for recurring tasks, and you will receive my feedback, without the expectation you’ll fix anything.

Until then: I’m happy with my patch, as it makes recurrent tasks working (except for the case I have to set an until-date. Then I get the next error message, and the tasks don’t arrive correctly on my mobile. File backend/kopano/mapiprovider.php: Line 443; $recurrence->proptags[“enddate_recurring”] is undefined, crashing the if-clause, because $recurrence->proptags[“enddate_recurring”] is undefined)

Again: I’m happy now. All I need at the moment works, and what does’nt work is what I don’t need. And holidays are near, so maybe I’ll fix more. And I’ll look if I can make my solution less invasive. My primary problem is one or two uninitialized variables/object entities or how these are called.

Over christmas, I was digging deeper into the recurring issues, and I was looking for less invasive way to make recurring tasks work. Manfred said, my prior way to generate recurrence information only on unfinished tasks is definitely the wrong way.

Here is the more or less better fix, adressing exactly three problems, where one completely breaks recurring tasks in Kopanos official release 2.4.5:

root@netprobe:/usr/share/z-push/backend/kopano#  diff mapiprovider.php mapiprovider.php-pbfix-v3 
<             $props[$taskprops["icon"]] = 1281;
>             if (!($task->complete)) {			// PB: fix icon usage:
>                 $props[$taskprops["icon"]] = 1281;	// PB: recurring-icon only for unfinished tasks
>             } else {					// PB: fix checkmark:
>                 $props[$taskprops["complete"]] = true;	// PB: without this, completed recurring tasks are not checkmarked
>             }						// PB: unfixed: due-date is wrong for completed recurring tasks
>             if (!(isset($recur["start"]))) {		// PB: start (required) undefined with Nine on Android
>                 $recur["start"] = $task->duedate ;	// PB: define it, as it's required
>             }						// PB: dunno, who's fault it is 

The code first fixes an issue with the icon: it should be the recurring-icon only for unfinished tasks. For those marked as done, the normal to-do icon is standard.

Next, the finished recurring task has the done-checkbox unchecked. My code fixes this, certainly at the wrong place, but it fits here well.

Finally, for reasons I could’nt find, $recur[“start”] is undefined if the task is not created without a future start date, so I fix this too. This removes the error message and fixes the outlook crashes when a task created in OL is marked as done on Nine, and the new instance created by Nine is marked as done in OL.

The fixed mapiprovider.php can be downloaded at, the old link has been disabled.

This fix clearly does not address all problems with recurring tasks, such as

  • when a recurring task is completed, it’s due-date is set to the next occurence of the upcoming task (I suspect this relates to the requirement to set $props[$taskprops[“complete”]] = true)
  • start date end end dates do not reliably work for me and need further testing

As always, use my fix at your own risk! I can not be made liable for any problem you might get with it, including silent data corruption or data loss.