Deleting calendar or task item causes 'Task' folder to be deleted

Wiz

Hello,

I have been struggling with this issue for quite sometime now and haven’t been able to find a solution -

Deleting a calendar or task item causes the account ‘Tasks’ folder, which is supposed to be a protected/system folder, to be deleted / moved to the ‘Deleted Items’ folder…

The only way to restore the Tasks folder is to recreate the account which is a pain!!

Kopano-ical log:

Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] New Request
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] Receiving headers:
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < DELETE /caldav/xxxxxx@xxxxxxxx.com/FLDPRFX_2EFDA5620D28498EA0D91566B311384A/ HTTP/1.0
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Host: yyy.yyyyy.yyy
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < X-Real-IP: x.x.x.x
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < X-Forwarded-For: x.x.x.x
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Connection: close
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Content-Length: 0
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Accept: */*
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < User-Agent: Fantastical 2 for Mac/2.3.8 Mac OS X/10.12.5 Darwin/16.6.0 (x86_64)
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Authorization: <value hidden>
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Accept-Language: en-us
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] < Accept-Encoding: gzip, deflate
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] Http::HrReadBody content-length invalid 0
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] > HTTP/1.1 204 No Content
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] > DAV: 1, access-control, calendar-access, calendar-schedule, calendarserver-principal-property-search
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] > Content-Length: 0
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] > Server: Kopano
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] > Date: Wed, 07 Jun 2017 19:08:28 GMT
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] > Connection: close
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] 127.0.0.1:44708 - xxxxxx@xxxxxxxx.com [07/Jun/2017:23:08:28 +0400] "DELETE /caldav/xxxxxx@xxxxxxxx.com/FLDPRFX_2EFDA5620D28498EA0D91566B311384A/ HTTP/1.0" 204 0 "-" "Fantastical 2 for Mac/2.3.8 Mac OS X/10.12.5 Darwin/16.6.0 (x86_64)"
Wed Jun  7 23:08:28 2017: [debug  ] [ 8720] End Of Request
Wed Jun  7 23:08:28 2017: [info   ] [ 8720] Connection closed

Why is this happening? Also, what is the easiest way to restore or recreate the Tasks folder?

UPDATE - tried recreating the systemfolder ‘Tasks’ using https://stash.kopano.io/projects/KSC/repos/core-tools/browse/recreate-systemfolders.py but the newly created folder isn’t promoted to a systemfolder ‘task’. It appears to be a normal folder as it is listed under the regular folders and not systemfolders ie. missing from the ‘Tasks’ tab in WebApp.

python recreate-systemfolders.py --user xxxxxx@xxxxxxxxx.com --create Tasks --systemfolder task

Regards

fbartels

@Wiz server versions are always appreciated when trying to reproduce an issue.

So you delete a task via Fantastical 2 through CalDAV and it deletes the whole folder?

Wiz

@fbartels Sorry, I’ll add those details to my signature.

OS: Centos 7 (latest release)
Product version: 8,3,1,15
File version: 15

To answer your question - yes, that’s exactly what happens. The folder gets moved to ‘Deleted Items’ and can only be seen if ‘Show all folders’ is selected in WebApp. No way to move or restore it back.

I can’t show you the folder under ‘Deleted Items’ now as I was troubleshooting the script mentioned above and it seems the folder is now lost.

Forgot to mention - This has been the case since Zarafa 7.x

UPDATE 2 - Not sure if this helps, the output of the recreate-systemfolders script when the ‘Tasks’ folder was in ‘Deleted Items’:

python recreate-systemfolders.py --user xxxxxxx@xxxxxxx.com --create Tasks --systemfolder task
User('xxxxxxx@xxxxxxx.com')
create tmp folder Tasks
Promote new folder to be a system folder

while the output changes to the following when the folder is no longer found anywhere:

python recreate-systemfolders.py --user xxxxxxx@xxxxxxx.com --create Tasks --systemfolder task
User('xxxxxxx@xxxxxxx.com')
create tmp folder Tasks
Traceback (most recent call last):
  File "recreate-systemfolders.py", line 103, in <module>
    main()
  File "recreate-systemfolders.py", line 52, in main
    tmp = user.store.subtree.create_folder(str(name))
  File "/usr/lib/python2.7/site-packages/kopano/folder.py", line 439, in create_folder
    folder = self.folder(path, create=True)
  File "/usr/lib/python2.7/site-packages/kopano/folder.py", line 365, in folder
    path = getattr(self.store, ENGLISH_FOLDER_MAP[path]).name
AttributeError: 'NoneType' object has no attribute 'name'

fbartels

@Wiz said in Deleting calendar or task item causes 'Task' folder to be deleted:

@fbartels Sorry, I’ll add those details to my signature.

no problem, but I would actually appreciate more to include that bit of information in the post itself. the signature can change, but if you include a version in the post this information is kept.

Forgot to mention - This has been the case since Zarafa 7.x

hmm… let me see if I can find a Mac somewhere to reproduce this.

Since you are using a supported version it can help priority wise to open a support case and have support reproduce the issue.

Wiz

thanks @fbartels - ticket KS-37981 has been opened.

robing

Hi,

As promised hereby the script that solved this issue

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import kopano
from MAPI.Util import *
import binascii


def opt_args():
    parser = kopano.parser('skpcf')
    parser.add_option("--user", dest="user", action="store", help="Username")
    return parser.parse_args()


def main():
    options, args = opt_args()

    if not options.user:
        print 'Please use: %s --user <username>' % sys.argv[0]
        sys.exit(1)
    user = kopano.Server().user(options.user)

    # Create tmp task folder
    # Some store can't create Task so we rename it later
    print 'Create Tmp Tasks  folder'
    taskfolder = user.store.subtree.create_folder('TMP-Tasks')
    taskfolder.container_class = 'IPF.TASK'

    try:
        taskfolder.mapiobj.SetProps([SPropValue(PR_DISPLAY_NAME, 'Tasks')])
        taskfolder.mapiobj.SaveChanges(KEEP_OPEN_READWRITE)
    except MAPI.Struct.MAPIErrorCollision as e:
        print 'Can\'t rename folder to Tasks\n', e
        user.store.root.delete(taskfolder)
        sys.exit(1)

    # promote to task folder
    print 'Promote Tasks folder'
    user.store.root.mapiobj.SetProps([SPropValue(PR_IPM_TASK_ENTRYID, binascii.unhexlify(taskfolder.entryid))])
    user.store.root.mapiobj.SaveChanges(KEEP_OPEN_READWRITE)



if __name__ == "__main__":
    main()

Regards,

Robin

Wiz

@robing Thanks again for the script :thumbsup:

I would appreciate if you could provide more information on why the caldav client was able to bypass the protected system folder’s permissions before I escalate the bug/issue with Fantastical’s dev team.

Best
Wiz