search

etesync / android

EteSync - Secure, end-to-end encrypted, and privacy respecting sync for your contacts, calendars and tasks.
https://www.etesync.com
GNU General Public License v3.0
305 stars 34 forks source link

Managing subtasks with Tasks.org broken #161

Closed devurandom closed 3 years ago

devurandom commented 3 years ago

When I create a task in Tasks.org and add subtasks, they become independent top-level tasks (i.e. no longer subtasks) as soon as I synchronise. This is a massive problem for me, since I organise my weekly shopping in this way (e.g. task "Shopping 2020/49" and subtasks for the items): I now have dozens and dozens of items floating around in my list, completely without any order.

Possibly related problems

One such top-level task ("Shopping 2020/47") was duplicated. Moving (completed) tasks from one of the duplicated top-level tasks to the other has the effect that they will be gone from both. One top-level task that I created for this week (i.e. named "Shopping 2020/49") vanished right after synchronising. I created another one with the same name and it is still there. Only the latter I can still see in the EteSync app's journal.

Time this started happening

This behaviour started roughly at the same time I migrated my account to EteSync 2 (between weeks 2020/42 and 2020/47, during which I did not create new tasks). Tasks that existed since before the migration appear to be unaffected. (Or are they just unaffected, because I do not touch them anymore?)

How I create tasks

My top level tasks are named "Shopping YYYY/WW" and have the tag "Shopping" and a due date set. Mostly I create them with subtasks right away. But even when moving other top-level tasks into them to make them subtasks shows the same buggy behaviour.

Other behaviour I noticed

When synchronising Tasks.org (go to top of list and pull down), I see the spinner display briefly, then about a second without and then it display again twice in quick succession (spinning for a few milliseconds, maybe a millisecond without spinner, then spinning again for a few milliseconds).

In EteSync's journal I can see the "raw" version of historic subtasks (i.e. older revisions). They carry a RELATED-TO;RELTYPE=PARENT:<decimal number> field. According to RFC 5545 Section 3.8.4.5 this should be the UID of the parent item. But the parent item has a UUID in their UID field, not a decimal number. The latest revision of the subtask does not carry that RELATED-TO field anymore.

I am also affected by the bug affecting setting tags in Tasks.org: #159

tasn commented 3 years ago

It sounds to me like a bug in tasks.org rather than EteSync. It looks like tasks.org is sending us the wrong task information (an internal reference) rather than the uuid. @abaker is it indeed an issue with tasks.org?

tasn commented 3 years ago

I just tested it here and I can indeed reproduce it locally. More than that, for me the main task is duplicated and sent twice to EteSync! It's either an issue in Tasks.org (sounds like it), or perhaps with the ical4android library. As this is not part of the EteSync code itself.

devurandom commented 3 years ago

Will you move this issue to the Tasks.org repo, or shall I open a new bug report there?

tasn commented 3 years ago

I pinged @abaker here, let's see what he says. I don't think I can transfer an issue to a repo I don't own, no? (actually no idea).

devurandom commented 3 years ago

I created tasks/tasks#1252.

tasn commented 3 years ago

Great, thanks!

devurandom commented 3 years ago

In EteSync's journal I can see the "raw" version of historic subtasks (i.e. older revisions). They carry a RELATED-TO;RELTYPE=PARENT:<decimal number> field. According to RFC 5545 Section 3.8.4.5 this should be the UID of the parent item. But the parent item has a UUID in their UID field, not a decimal number. The latest revision of the subtask does not carry that RELATED-TO field anymore.

Just for my own understanding: Could you please explain how the fix of 4e472e5ff3cc00cab880bce7f7d0091dde4db3c4 interacts with what RFC 5545 demands? I.e. how did generating a UID (I assume for the parent task?) cause the subtask to contain the wrong RELATED-TO? Was the problem caused by Tasks.org assuming that it is in control of the UID of the parent and using its own value when setting RELATED-TO on the subtasks instead of checking which UID EteSync actually set?

tasn commented 3 years ago

The change has nothing to do with the RFC, the bug was elsewhere. Essentially what was going on is this: Tasks.org was using its internal IDs as UIDs in (completely legal), and EteSync was overwriting the IDs with its own UIDs for new items which meant that the IDs Tasks.org was expecting ended up being wrong. They were the UIDs generated by EteSync instead of the IDs that Tasks.org expected and were set in related-to.

devurandom commented 3 years ago

FYI: @abaker said in tasks/tasks#1252 that this is fixed. It should just need a new release of EteSync now.

devurandom commented 3 years ago

The EteSync 2.2.3 update just arrived on F-Droid. After installing it, I synchronised EteSync, then I synchronised Tasks.org (using version 11.0), then I tried to move the subtasks that were forced out of their parent back into it and synchronised Tasks.org. The subtasks were moved out of their parent again. This is not fixed, yet.

devurandom commented 3 years ago

The EteSync 2.2.3 update just arrived on F-Droid. After installing it, I synchronised EteSync, then I synchronised Tasks.org (using version 11.0), then I tried to move the subtasks that were forced out of their parent back into it and synchronised Tasks.org. The subtasks were moved out of their parent again. This is not fixed, yet.

@abaker suggested in https://github.com/tasks/tasks/issues/1252#issuecomment-749741295 that this might not be fixed before Tasks.org 11.0.1. That just arrived on F-Droid. I can happily confirm: It fixes the problem.

tasn commented 3 years ago

Great news, and sorry again for the trouble! It was a tough one that as you saw spread across the two apps. Thanks!