Nested lists (sublists) / folders

[Braintelligence]

I'm thinking of something like a list CLIENTS with other lists Client A, Client B, Client C and so on. If I create a task in the list Client A, then I will see the task in Client A and CLIENTS. If I create a task in Client B as well I can see it in Client B and CLIENTS but not in Client A.

I don't know, though, if this can be projected to apps like OpenTasks after implementation.

[Chaos99]

Subscribing here to watch for development of folders/multiple lists per calendar.
At the moment, subtasks could be used to implement a hierarchy, but OpenTasks does not support them (or, better: it supports them differently, so they don't sync properly).
Is there any known workaround to this except creating new (empty) calendars just to hold tasks lists?

[raimund-schluessler]

The CalDAV standard does not define a way to manage nested lists or folders afaik. So what ever we implement here, it will not work on other clients unless they implement it the same way.

[Chaos99]

For subtasking I think using the RELATE-TO field as you already do is a good solution. But you are right that it's not part of RFC4791 and it still awaits implementation in the app (dmfs/opentasks#341).

Folders could be implemented in a similar manner with marking the topmost VTODO with a custom field to be treated as a folder instead of a task by the UI. Although you are right that this too depends on adoption by the app developers. (But this approach offers a convenient fallback solution of showing them as tasks with subtasks in case the custom field is not supported.)

I believe it's appropriate for the server infrastructure to take the leading role in standardizing those custom formats instead of waiting for the app developers to come up with a whole set of different implementations.

[Qub1]

Would it be a good idea to implement sublists by using a Calendar / List naming scheme of List/Sublist/Subsublist?
For example, if there's a list named A and a list named A/B, the second would appear as a sublist of A with the name B. This would also make the names of lists in external applications that do not implement sublists more user-friendly.
Gmail uses the same strategy for labels and the way they're displayed.

The only drawbacks would be that slashes would have to be escaped somehow, and that it is not clear how a list called A/B would be handled if the list A does not exist.

[rusitschka]

With Nextcloud I can create nested tasks and they are displayed correctly. But OpenTasks shows them in a flat way. How does Nextcloud store these nested issues? Does it use RELATE-TO or does it have its own mechanism?

[raimund-schluessler]

With Nextcloud I can create nested tasks and they are displayed correctly. But OpenTasks shows them in a flat way. How does Nextcloud store these nested issues? Does it use RELATE-TO or does it have its own mechanism?

We follow RFC 5545 https://tools.ietf.org/html/rfc5545#section-3.8.4.5 here and use RELATED-TO, see https://github.com/nextcloud/tasks/blob/master/src/models/task.js#L305. Every other app following this standard would show it correctly.

[rusitschka]

RFC 5545 explicitly states related-to being a child relationship - and only that, right? I.e. circular dependencies are not allowed?

[raimund-schluessler]

The task which has this property, by default references its parent. But you can state other relationship types such as child or sibling: https://tools.ietf.org/html/rfc5545#section-3.2.15

Circular dependencies are not explicitly forbidden, as far as I know. So you could have two tasks referencing each other as parent for example. But I think this doesn't really make sense.

To be honest, I don't really know how the Tasks app would behave if it encounters a circular dependency. I guess it would crash or at least slow down a lot.

[rusitschka]

Maybe that's the reason the feature has not been implemented in OpenTasks, yet. Maybe we need a "CHILD-OF" relationship and get rid of "RELATED-TO" because it's too generic. Do you know how to trigger such an RFC change/update?

[raimund-schluessler]

Maybe that's the reason the feature has not been implemented in OpenTasks, yet. Maybe we need a "CHILD-OF" relationship and get rid of "RELATED-TO" because it's too generic. Do you know how to trigger such an RFC change/update?

Why should that be to generic? It does exactly the same as your proposed "child-of". No reason to rename this property.

[rusitschka]

Ok, yes I see. Together with RELTYPE=CHILD it's exactly what we need.

[BlipRanger]

For clarity, is this issue the same reason that when you sync iOS reminders via CalDAV you cannot have subtasks?
(iOS won't let you make them in the synced list and when you make them on NC they get flattened on the iOS list)

[raimund-schluessler]

For clarity, is this issue the same reason that when you sync iOS reminders via CalDAV you cannot have subtasks?

(iOS won't let you make them in the synced list and when you make them on NC they get flattened on the iOS list)

No. iOS reminders simply does not support subtasks. This is a limitation of iOS reminders we can not fix. Please contact Apple for this feature.

[BlipRanger]

For clarity, is this issue the same reason that when you sync iOS reminders via CalDAV you cannot have subtasks?
(iOS won't let you make them in the synced list and when you make them on NC they get flattened on the iOS list)

No. iOS reminders simply does not support subtasks. This is a limitation of iOS reminders we can not fix. Please contact Apple for this feature.

Interesting, I did a bit more reading and while you can create subtasks in the Reminders app (I just did it myself), I've seen that it seems that they have screwed the way it works with CalDAV.

[meichthys]

iOS reminders simply does not support subtask

It looks like iOS does now support subtasks - just not when syncing with a CalDAV server. This probably means that Apple is implementing the subtasks in a proprietary/non-standard way.

[Medius7]

I would like to see sublists in NC tasks:

Currently I'm using ToDoIst, which supports a list hierarchy. This makes it possible to share a list with someone else, and then create separate lists for different projects within the shared list. This means that these sublists automatically inherit the "Shared Properties" of the parent list.

I find there are clear advantages to using sublists instead of subtasks.
Sublists are clearer and easier to manage. Especially when there are many entries.