[Feature Request] Support 2Do subtasks creation

[raimund-schluessler]

Originally posted by @bcutter in #23 (comment)

I´m a bit confused on this different behaviour, now reading all your posts understanding why (every app seems to implement an own way of creating a sub-sub-task hierarchy).

My experience:

[1] NC Tasks to 2Do:

1. NC tasks web app: creating root tasks, assigning sub tasks => 2 levels
2. Sync those with 2Do app (iOS & Android)
3. View them in 2Do app: all shown flat as root tasks, hierarchy information is lost.

[2] 2Do to NC Tasks:
The other way around is working great indeed:

1. 2Do app: creating root tasks (type "project" or "checklist"), assigning sub tasks => 2 levels
2. Sync those with NC server
3. View them in NC tasks web app: shown correctly with full hierarchy information

But: the way "[2] 2Do to NC Tasks" is limited to only 2 level hierarchies. Adding sub tasks to sub tasks (3 levels) or more is not possible. Vice versa I can create a lot of levels in NC tasks web app (tested to 5 levels), but those are not synced correctly as described in way "[1] NC Tasks to 2Do".

It´s quite frustrating, having a great server/web app and a great endpoint app seeing both are not really working together. As a workaround I created some "spare" or "template" checklists/projects (tasks able to have child tasks) with the 2Do app, being able to use (rename, move and !!! add sub tasks which permanently stick to their parents !!!) them with the NC tasks web app. Not the best user experience, cause it´s not consistent... :-)

...but the workaround shows: NC tasks app can (and currently does!) SUPPORT those parent-child-connection (I don´t know which technique is used by 2Do app when selecting "project" or "checklist"), but it doesn´t create it. That would be SO powerful!

[raimund-schluessler]

@bcutter This issue is about nested lists, not tasks/subtasks. But since we are here anyway:

I have never used 2Do app yet, but I quickly gave it a test (latest version from the iOS appstore) and I can confirm your findings. The problem is that 2Do does not (only) rely on the iCalendar specs, but stores its own metadata in a custom field of the task:

X-2DOAPP-METADATA;SHARE-SCOPE=GLOBAL:<2Do 
 Meta>%7B%22RecurrenceValue%22%3A0%2C%22RecurrenceEndRepetitionsOrig%22%3A0
 %2C%22uid%22%3A%22ec1ccbc186c94bbcb6672301bf0390a5%22%2C%22RecurrenceEndRe
 petitions%22%3A0%2C%22TaskType%22%3A1%2C%22TaskDuration%22%3A0%2C%22Recurr
 enceType%22%3A0%2C%22StartDayDelay%22%3A0%2C%22isExpandedToShowChildProjec
 ts%22%3A0%2C%22RecurrenceFrom%22%3A0%2C%22RecurrenceEndType%22%3A0%2C%22Is
 Starred%22%3A1%2C%22RUID%22%3A%22%22%2C%22DisplayOrder%22%3A0%7D</2Do 
 Meta>\n

It seems that only when a field (don't ask me what exactly) in this meta-data is present the 2Do app treats a task as a checklist. When a task is recognized as a parent/checklist task, then the standard RELATED-TO property which NC Tasks uses to store parent/child relationships is evaluated and subtasks are shown correctly. We would need to properly add this meta-data for parent tasks, but without any documentation/support from 2Do this won't work. And to be honest, if 2Do would simply use the CalDAV standard it would work immediately with NC Tasks (and at least for the parent/child relations I don't see a reason to use any custom meta-data field).

[guidedways]

We actually do use RELATED-TO but perhaps I've given up since although this is part of the spec, absolutely no one (other than NextCloud it seems) supports it. I'm thrilled to read that this is supported by NextCloud and will look into keeping this property in sync.

The trouble is that rogue clients can either remove this property entirely at times or overwrite it with some other junk (I've seen this in the past). This has resulted in a lot of headache in the past where people have lost linkage between parent / sub-tasks and I think at some point I just gave up and rely solely on 2Do's own meta-data. I may have to do something special for NextCloud or simply add an option for users to "turn ON".

[raimund-schluessler]

@guidedways Great to have you here!

We actually do use RELATED-TO but perhaps I've given up since although this is part of the spec, absolutely no one (other than NextCloud it seems) supports it.

I am also not aware of any other client really doing it like this. But since I wanted to support subtasks and follow the standard, that's what I thought was most reasonable. I am happy you use this as well.

The trouble is that rogue clients can either remove this property entirely at times or overwrite it with some other junk (I've seen this in the past).

I haven't got any reports that clients broke this property (so far at least). I wonder why they would do it and not just ignore the property entirely.

This has resulted in a lot of headache in the past where people have lost linkage between parent / sub-tasks and I think at some point I just gave up and rely solely on 2Do's own meta-data.

That's understandable given your experience with the property being removed.

I may have to do something special for NextCloud or simply add an option for users to "turn ON".

I think there are two options here:

• 2Do takes the RELATED-TO property into account when checking if a task is a parent task (list / project in 2Do terms) and displays them accordingly
• The Nextcloud Tasks app also writes the 2Do Metadata, so the app can handle it

To be honest I would prefer the first approach, because it would strictly follow the CalDAV standard without custom meta-data. However, I don't know the internals of the 2Do app. If the first approach creates a lot of trouble, we can also just add the 2Do meta-data field. This would probably require a request to alter the parent task (not necessary at the moment) and you would need to support me writing the meta-data, since I am afraid of breaking something in your meta-data field which would mess up the tasks in the 2Do app.

PS: To be honest, I don't really understand the difference of a project / list in the 2Do app yet, so forgive me if I messed something up here.

[tbm]

@guidedways has there been any progress in implementing RELATED-TO in 2Do? It would be nice to have interoperability between 2Do and Nextcloud Tasks.

[HackintoshHD]

@guidedways I'm fully aware software releases are ready when they're ready. But is there maybe any sort of status update concerning 2Do's subtask handling or any chance to at least confirm the RELATED-TOimplementation request got onto the 2DO roadmap?

[guidedways]

@HackintoshHD I hear you. As much as I would want to (and love to) support this - the problem is that most CalDAV clients and servers don't support this. The real issue I have is with 3rd party clients "removing" this property or overwriting it with bogus / stale data during sync and creating a confusion as far as 2Do is concerned. I've in fact supported this (briefly) in the past, only to later sync "one-way", i.e. 2Do would set this property when pushing changes to the server, but won't care about its value when it pulls a task in. Most of the times this property gets removed by a client when it re-constructs the ICS data during sync.

When that happens, 2Do has to rely on its internal meta-data. The problem with the internal meta-data is that some rogue client could in theory save a stale copy internally and send back this stale copy with a parent-UID that no longer exists. I've seen this happen before. Right now, 2Do is able to make an intelligent guess and resolve such a conflict when it happens, but if it were to rely on yet another property that isn't properly supported, we'll end up with a scenario where we don't know which UID to trust.

This isn't impossible to "fix" - 2Do could just treat NextCloud differently and support it natively. I wouldn't want NextCloud to deal with X-2DOAPP-METADATA as it's just ugly. Again, we'll end up breaking something. It's already pretty fragile when we're at the mercy of rogue 3rd party clients that have little regard for X-properties they don't recognize.

Currently 2Do's internal Sync-related code is being re-written / ported to Swift and I think it would make more sense to look into this again when I'm ready. Very difficult to pin down a date but I've got this high up in the todo-list to come back to and re-consider.

[HackintoshHD]

@guidedways Thank you for the status update and for making the decision process on Nextcloud Tasks subtask compatibility transparent. I understand the reasons behind your decision. I'd be more than happy, of course, if this current decision to initially not support Nextcloud Tasks' subtasks could be reconsidered once the code's Swift rewrite is nearing completion (like possibly others here, I've bought 2Do and BusyCal and together with a (read-only) instance of Thunderbird, they're the only CalDAV clients involved in my sync workflow - from what I understand, this should make most of the problematic points mentioned above irrelevant).

Maybe the feature could have some sort of 'hidden' status, e.g. like Firefox/iOS' feature to define custom sync servers (= five taps on app info to display the enabling switch), and an 'unsupported for the following reasons, you have been warned' dialog? That would enable users with sufficient background knowledge to use the feature while the standard user wouldn't get in touch with it and thus wouldn't cause support time.

[HackintoshHD]

Just FYI and for reference, in case people interested in this thread would like to support it: A very same feature request for Thunderbird.

[feluxe]

absolutely no one (other than NextCloud it seems) supports it.

@guidedways The Tasks app for Android can sync sub-tasks with Nextcloud sub-tasks. It works very nicely.

I tried to use 2Do with my nested nextcloud tasks, but it's simply unusable the way it is... so removed it.