ForumsQuestionsSetting for subtasks to always inherit folder from parent
Setting for subtasks to always inherit folder from parent
| Author | Message |
|---|---|
|
safire |
I've been working on org-toodledo (emacs integration with org-mode) and been thinking about how to add folder support and as a result I have a feature request.
Basic problem: There is no strict relationship between the folder assignment of tasks and subtasks. Feature Request Add a setting to Subtasks: [x] Subtask's folder always inherits from it's parent This would work as follows: 1. Creating a subtask C of task P sets C's folder to that of P 2. Making an existing task C a child of task P sets C's folder to that of P, even if C previously had a different folder assigned. 3. Promoting a subtask C to a top-level task retains the folder assigned to it. 4. Make the setting available via the Developer's API Details I spent a fair amount of time searching the forums for discussions about this topic, and here's what I've gathered. Folders are not really much more than a special tag on a task which enables filtering. In the sense that you can build a view that is restricted to a single folder gives the impression that the folder provides grouping. However, this is not much different than the view by context or tag. In fact there has certainly been confusion on the list about the difference between the proper use of context versus folder. If used according to GTD, context denotes something about where a task can be completed, thus has some special meaning that can be leveraged. But I can find no such special meaning for folders. It is clear that some folks use folders just like a special tag. Proximo's famous GTD methodology uses folders in this way, assigning the task to a folder to denote the state of a task (Inbox, Actions, Projects, Waiting...). There is already a Status field for each task that performs almost the same function, which some have pointed out. As I understand it, Proximo simply used Folder as it provided the flexibility needed to implement GTD in a way that made sense to him. However, the standard concept of a folder really does not apply. By that I mean a folder is generally a fairly rigid grouping construct. If you put an item in a folder, that item and all of its dependencies are in that folder. Currently, Toodledo with folder as an attribute allows for the following: * Parent task (Folder=FOO) ** Subtask 1 (Folder=BAR) ** Subtask 2 (Folder=None) Expected behavior: * Parent task (Folder=FOO) ** Subtask 1 (Folder=FOO) ** Subtask 2 (Folder=FOO) In this way, folder really need only be assigned to top-level tasks (or alternately read-only for subtasks). It could be better visualized as follows: * Folder FOO ** Parent task *** Subtask 1 *** Subtask 2 This is much more intuitive to me, and now gives "folder" a special meaning apart from a tag -- a task and all it's subtasks are part of the folder. Moving the task to a new folder changes all the sub-tasks as well. This is not a behavior I want for tags in general. Why do I care? As I implement this in Emacs org-toodledo, I cannot find any way to meaningfully distinguish between a "folder" and a "tag", other than the fact that a task can only be associated with one folder, which doesn't seem terribly interesting to me. I had hoped to use folder as a higher level construct like my example above, and the user can certainly create views of tasks by filtering on folder, but such a view is no different than filtering on any other tag. Given that there are no doubt plenty of users that use folder as a tag and have subtasks with different folders (like the first example), I don't really expect a wholesale change here, the feature request for a new setting to enable this behavior. This message was edited Feb 20, 2012. |
|
Jake Toodledo Founder |
Yes, you could look at folders as being nothing more than special tags, but folders to have some extra functionality.
1) You can archive folders 2) You can control who collaborators with you via folder permissions 3) Folders can be manually ordered Thanks for the suggestion about having an option to force subtasks to have their parent's folder. This was an initial constraint that we had when subtasks were first released, but we relaxed this constraint by popular request. It might be worth looking into making this a user configurable option. |
|
avbudin |
That would greatly help, thanks for suggesting and researching it!
|
You cannot reply yet
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.