[BUG] No sync between TW status:deleted and CalDAV STATUS:CANCELLED

bjornfor commented 1 year ago

Describe the bug

I noticed that my Taskwarrior status:deleted tasks are not synced to CalDAV.

To Reproduce

Have Taskwarrior data with at least one deleted task
Sync to CalDAV
Notice the deleted task is not copied to CalDAV

Expected Behavior

I expect deleted Taskwarrior tasks to be synced to CalDAV with STATUS:CANCELLED.

Versions

Latest master branch (v1.5.1+).

`--version` of your executable

$ tw_caldav_sync --version
tw_caldav_sync, version 1.5.1

Additional context

I'm migrating from Taskwarrior to CalDAV, and I have tasks going back 8+ years and want to preserve history.

github-actions[bot] commented 3 months ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

bjornfor commented 3 months ago

Not stale.

bergercookie commented 3 months ago

I cannot reproduce it with the latest 1.8.7 version of the tool

13:53:39.10 | DEBUG     | Initialising...
13:53:39.10 | DEBUG     | Initialising preferences manager -> /home/berger/.config/test_syncall
13:53:39.10 | INFO      | Loading preferences...
13:53:39.10 | DEBUG     | Loading cached configuration - test_tasks__modified.after%3A-30d__None__.yaml
13:53:39.10 | INFO      |

Configuration:
===============

  - TW Filter             : modified.after:-30d
  - TW Tags               : ()
  - TW Project            : None
  - TW Sync All Tasks     : False
  - Caldav Calendar       : test_tasks
  - Prefer scheduled dates: False

13:53:39.10 | DEBUG     | Initializing Taskwarrior instance using config file: /home/berger/sync/bulk/src/syncall-for-prs/.taskrc
13:53:39.10 | DEBUG     | Attempting to read radicale-server/users/berger from UNIX Password Store...
13:53:39.41 | DEBUG     | Using a custom configuration file ... -> test_tasks__modified.after%3A-30d__None__.yaml
13:53:39.41 | DEBUG     | Initialising preferences manager -> /home/berger/.config/test_syncall
13:53:39.41 | INFO      | Loading preferences...
13:53:39.41 | INFO      | Initializing Caldav...
13:53:39.41 | DEBUG     | Connected to calendar test_tasks
13:53:39.42 | DEBUG     | Connected to calendar - test_tasks
13:53:39.42 | INFO      | Initializing Taskwarrior...
13:53:39.43 | DEBUG     | Using the following filter to fetch TW tasks: ( modified.after:-30d )
13:53:39.44 | INFO      | Detecting changes from caldav...
13:53:39.44 | DEBUG     |

New Items:      0
Modified Items: 0
Deleted Item:   0

13:53:39.44 | INFO      | Detecting changes from Tw...
13:53:39.44 | DEBUG     |

New Items:      0
Modified Items: 0
Deleted Item:   1
        d1e06d60-bda6-42d9-b811-e2cec5ac8c82
13:53:39.44 | INFO      | [caldav] Synchronising deleted item, id -> 5e3c1803-5bba-11ef-9ab9-ebd9c3170386...
13:53:39.46 | WARNING   |

Caldav
------
        * Items created: 0
        * Items updated: 0
        * Items deleted: 1

Taskwarrior
-----------
        * Items created: 0
        * Items updated: 0
        * Items deleted: 0

13:53:39.46 | SUCCESS   | Sync completed successfully. You can now use the -b/--combination option to refer to this particular combination

  tw_caldav_sync --combination test_tasks__modified.after%3A-30d__None__.yaml

bergercookie commented 3 months ago

There's been quite a few changes in tw_caldav_sync since the 1.5.1 version. Please have a go with the latest one, 1.8.7, published on pypi and let me know if it still doesn't work; I'll close it for now

bjornfor commented 3 months ago

@bergercookie: Thanks!

bergercookie commented 3 months ago

Actually, the behavior of the tool is different to the docs - i.e., we're not syncing the tw deleted property to the CANCELLED property but rather we're deleting the item altogether at the caldav side.

At the moment I find this behavior reasonable so I may change the docs to reflect this but I'm not a regular caldav user so I'd be interested in other people's thoughts. @bjornfor ?

bergercookie commented 3 months ago

One issue with the current approach is that when tasks are marked as cancelled from caldav, tw_caldav_sync then deleted the item in TW and, on the subsequent sync, also deletes the (cancelled) task in caldav.

This isn't ideal. Probably, a better mapping would be to mark the cancelled items as completed when syncing Caldav -> TW so that then on subsequent syncs tw_caldav_sync takes no further action

bjornfor commented 3 months ago

At the moment I find this behavior reasonable so I may change the docs to reflect this but I'm not a regular caldav user so I'd be interested in other people's thoughts. @bjornfor ?

I'm not sure what you're saying here. You closed the issue because you cannot reproduce the issue (i.e. issue fixed), but at the same time I think you're saying the issue is invalid? I'm no CalDAV expert, but from my perspective, the issue is (was?) valid and I think TW status:deleted should be synced with CalDAV STATUS:CANCELLED.

bergercookie / syncall