You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FR]: Allow subtasks to inherit project link from the parent task's project #518
Unless I'm mistaken, this feature doesn't exist yet, but it would be very useful. Would it be possible to create a subtask so that it inherits the link to the project that was assigned to the main task?
This would make it easier to use BASE for task-specific filters. What do you think ?
Hi @bepolymathe . I'll have a think about this. I might think about adding support for a bunch of new template variables--{{parent.project(s?)}}, {{parent.status}}, {{parent.priority}}, etc. But making this useful might be dependent on a more robust templating system (where users can perhaps select from different templates upon task creation). I'll have a think about it!
Possibly adding a new property parent would be sensible. This property would behave like projects does currently when creating a subtask.
This would allow a subtask to inherit its parents projects, and have a link to its parent task. So the task hierarchy isn't lost. (A subtask should only be able to have 1 parent imo but could be dependent on other tasks)
Inheriting the parents projects has pros and cons so this might be better to be templated as has been suggested. Or alternatively a toggle option in the settings
Agreed!
One frustrating thing when creating subtasks is having to go back and add it to the main task (especially when creating some in bulk from a brain dump). Cumbersome. At the very least the project context when converting should transfer if it exists (when added to the main task note).
Agreed - I don't want to use the parent note as the project, but I want the project from the parent note to be the project for the task. Something like {{parent.project}} would be ideal.
Unless I'm mistaken, the latest update has the following effect:
a task created as a subtask from the "modal" assigns the parent task as a project to the created task ✔️
a task created from a project file (via the banner at the top/bottom of Notes) registers the project file as a project ✔️
a task created from another location (via the "create a new task" command) writes the file where you are located as the project. 🤔
The first two cases are fine, and that's what we were discussing. However, the third case is more problematic because it breaks workflows based on an "inbox" logic. If I enter a task on the fly while I'm in the calendar, then I'll have calendar-default.base as the project. That's not ideal.
I propose a more sophisticated approach. When a task is created from a file that is neither another task (tag:task) nor a project file (tag:projects)... then the file contains no projects and must be clarify as an inbox task.
Yeh I had a play with the latest update and the current implementation didn't suite my needs so I uninstalled again. I can explain the issues when I get time again if it is useful
Activity
tomsymonds commentedon Sep 3, 2025
+1 for this
callumalpass commentedon Sep 7, 2025
Hi @bepolymathe . I'll have a think about this. I might think about adding support for a bunch of new template variables--{{parent.project(s?)}}, {{parent.status}}, {{parent.priority}}, etc. But making this useful might be dependent on a more robust templating system (where users can perhaps select from different templates upon task creation). I'll have a think about it!
bepolymathe commentedon Sep 8, 2025
Thank you for your reply. Using a more sophisticated template system would certainly be a good solution... based on standards and flexible.
AndyEveritt commentedon Oct 14, 2025
I also think this would be a good feature.
Rather than inventing a new template system. Maybe expanding on the existing templater would be better since that is quite widely used and robust
AndyEveritt commentedon Oct 14, 2025
Possibly adding a new property
parentwould be sensible. This property would behave likeprojectsdoes currently when creating a subtask.This would allow a subtask to inherit its parents projects, and have a link to its parent task. So the task hierarchy isn't lost. (A subtask should only be able to have 1 parent imo but could be dependent on other tasks)
Inheriting the parents projects has pros and cons so this might be better to be templated as has been suggested. Or alternatively a toggle option in the settings
wedgen commentedon Mar 12, 2026
Agreed!
One frustrating thing when creating subtasks is having to go back and add it to the main task (especially when creating some in bulk from a brain dump). Cumbersome. At the very least the project context when converting should transfer if it exists (when added to the main task note).
lindsaylearns commentedon Mar 20, 2026
Agreed - I don't want to use the parent note as the project, but I want the project from the parent note to be the project for the task. Something like
{{parent.project}}would be ideal.callumalpass commentedon May 19, 2026
Thank you for reporting this. This should be resolved in release 4.8.0, so I am going to close this issue now.
bepolymathe commentedon May 20, 2026
Hello everyone,
Unless I'm mistaken, the latest update has the following effect:
The first two cases are fine, and that's what we were discussing. However, the third case is more problematic because it breaks workflows based on an "inbox" logic. If I enter a task on the fly while I'm in the calendar, then I'll have
calendar-default.baseas the project. That's not ideal.I propose a more sophisticated approach. When a task is created from a file that is neither another task (tag:task) nor a project file (tag:projects)... then the file contains no projects and must be clarify as an inbox task.
What do you think? @callumalpass @AndyEveritt @lindsaylearns
AndyEveritt commentedon May 20, 2026
Yeh I had a play with the latest update and the current implementation didn't suite my needs so I uninstalled again. I can explain the issues when I get time again if it is useful