RFC 9253 reltypes get overwritten as reltype=parent

[Zocker1999NET]

RFC 9253 specifies new RELTYPE which are not known nor supported by Tasks. Tasks seems to interpret the new relation types (and the other new as well) as RELTYPE=PARENT, which was correct behavior following RFC 5545.

EDIT: I thought at first that Tasks only displays an example todo of mine with RELTYPE=DEPENDS-ON as a subtask. However, it seems to overwrite the RELTYPE. This makes Tasks fully incompatible to other calendar implementations wanting using the new relation types.

I’m sure that Tasks overwrites this as:

• The example code I used has no offline copy, it works directly on the CalDAV server. My CalDAV server is Nextcloud. When a todo with DEPENDS-ON is pushed to Nextcloud & retrieved afterwards, it still has the correct RELTYPE.
• After some time & after forcing Tasks on my phone to sync with the server, the RELTYPE suddenly changes.
• My own example code & Tasks & Nextcloud’s own integrated tasks app are the only clients accessing the CalDAV server. Nextcloud’s tasks app does not support any relation at all & was not opened while the todo was modified. So Tasks seems the only client left.

I want to help in verifying this with logcat from Tasks, but I’m unsure if & how that would be logged.

(This issue relates to #1202 as some new relation types might be used to represent the use cases described there.)

APPENDIX: I think that this might be relevant: I’m using DAVx5 for synchronization, not the integrated CalDAV synchronization engine.

EDIT: Text before discovering Tasks overwrites the other types

However, when using Tasks together with other systems supporting the new RFC 9253, behavior occurs which is unexpected for users: E.g. a task with RELTYPE=DEPENDS-ON is shown as a subtask of the task it depends on. This may seem correct in the first glance, however, when completing the super task, Tasks automatically completes the dependent task as well. However, IMO DEPENDS-ON is added for cases where the dependent task is a separate thing to do which can only be completed after the other task was completed.

I don’t know the code base (so please correct me if I’m wrong here), but it should be relatively easy to ignore the new RELTYPEs until they are supported properly. This should increase UX by a little bit.

[abaker]

The code is supposed to ignore other reltypes, and only treat explicit parent or missing reltypes as parent. Can you send me an example ics file and I'll write a unit test?

[abaker]

nevermind, don't need a test. this is actually an issue in ical4android: https://github.com/bitfireAT/ical4android/blob/76e30b7ebd9660d0cbd1849f50a5003ae498374c/lib/src/main/kotlin/at/bitfire/ical4android/AndroidTask.kt#L294

Anything that is not a CHILD or SIBLING gets treated as PARENT

[abaker]

Can you try Tasks.org's CalDAV sync and see if you have the same issue?

[Zocker1999NET]

Thanks for the fast answer. Don’t have the same issue there, so that’s a viable workaround.

So this seems to be an issue of DAVx5 (or its libraries)?

[abaker]

Yeah, ical4android is provided by the DAVx5 devs as well. Tasks uses ical4android for its direct CalDAV sync, but doesn't use the line of code I linked earlier. That code does get used somehow during DAVx5 sync.

[rfc2822]

How should DAVx⁵ store such a RELTYPE for tasks.org? There's no possibility in the current OpenTasks contract. Is there be a separate contract to directly access tasks.org and advanced fields like a custom relation type?

[abaker]

Ah so does the open tasks content provider only allow these two values? I didn't look that deeply

Tasks only uses the parent reltype, the issue seems to be another client is setting other reltypes.

Would it be enough if I updated the content provider to allow arbitrary values?

[rfc2822]

Would it be enough if I updated the content provider to allow arbitrary values?

Yes, that should help. There could be new constants for the RFC 9253 values, and optionally a field for custom values.

However I think it should be compatible to OpenTasks so that OpenTasks at least doesn't crash with these values. On long term, the question is whether tasks.org will "fork" and modify the OpenTasks contract over time (or whether there will be a completely new, different tasks.org contract), and how compatibility will be handled. Anyway, OpenTasks seems to not be developed anymore.