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



  • 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


  • Kopano

    @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?



  • @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.

    0_1496866276454_2017-06-08_00-10-57.png

    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'
    

  • Kopano

    @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.



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


  • Kopano

    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



  • @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


Log in to reply
 

Looks like your connection to Kopano Community Forum was lost, please wait while we try to reconnect.