Introduce the concept of task dependencies

[AlyMoh]

Hi all. First of all, I'd like to thank everyone who has contributed to this great plugin. It's allowing me to use Obsidian as a jack-of-all-trades for many tasks including organization and task planning!

I'm also an avid user of Taskwarrior, and one of its incredibly neat features is setting dependencies for tasks.

This allows for the following:

• Better and possibly more accurate urgency scores: Tasks that cannot be started or completed without first finishing some task(s) would understandably have a lower urgency score since they cannot be worked on until the tasks on which they're dependent are completed.
• Better organization: Aside from the urgency calculation, one could have a better overview of which tasks they can work on in the first place and get straight to completing tasks that are open.

I couldn't find any equivalent discussions on the same features. If there happens to be one, I apologize for the duplicate discussion thread. Otherwise, I'd like to hear your thoughts on this idea and whether it'd be something worth considering in a pull request.

Thank you all and have a nice day! :)

[schemar]

Hey @AlyMoh, thank you for your feedback. Task dependency is not possible at the moment. But it's a good idea.

[therden]

@AlyMoh and @schemar: a description of how I manage task dependencies using Obsidian Tasks follows below.

Within the note that contains them, each blocking task is assigned the #blocking tag, and each dependent task is distinguished in the following three ways:

1. They are listed beneath the task that they depend upon;
2. they are indented one level from the task that they depend upon; and
3. until their dependency is satisfied, they take the form of a list item (not a task.)

Here's a contrived-but-illustrative example:

### Project with several tasks, some of which are dependent on others
- [ ] This is a #blocking task
   - This will remain a list item until the above task is completed; it is, in turn, #blocking the following task
      - And _this_ list item won't become a task until the one immediately above is completed
      - [ ] This task is independent of all others (it is indented for some other reason)
   - This item also won't be converted to a task until the first level task directly under the project header is Done
- [ ] This task is independent of all others

At least once a day I review my "Update dependencies" note, which contains the following query:

```tasks
done
description includes #blocking
```

I use the backlinks in the query results to open the notes that contain completed tasks with the #blocking tag. In each, I

• delete the #blocking tag from now-completed items, and
• convert now-unblocked list items into tasks (by placing the cursor inside them and pressing Ctrl-Enter once)

Although this approach does not support tasks with multiple, independent dependencies for a single task, I have found that it works well enough for my purposes, and am sharing it in the hope that it will be useful to others.

[hollyhudson]

Thank you all for discussing these work arounds for blocking/sequential tasks. I have severe ADHD and this a key task manager feature that I haven't found actually supported in a task manager yet, but I really need it! I like the idea of @therden 's approach in that it forces you to actually check your blocking tasks every day, but lol, I know in reality I won't actually work for me. If I see a task every day that I can't complete it becomes visual noise that my brain quickly learns to tune out. And seeing undoable tasks over and over is the sort of thing that makes me stop looking at my task list altogether. So I think @njwfish 's approach -- automating re-tagging when blocking tasks are completed -- is the better choice. But, actually trying to implement it is not something I know how to do, unfortunately.

[OogieM]

Thank you all for discussing these work arounds for blocking/sequential tasks. I have severe ADHD and this a key task manager feature that I haven't found actually supported in a task manager yet, but I really need it!

This requirement is why I can't move all my task management into Obsidian. I use Omnifocus which has the concept of both sequential projects, in which the tasks are hidden and not shown until the task before it is done, and parallel projects in which all tasks are available at once. Sequential is how 154 of my current 160 active projects are set in Omniocus. I have it set as my default mode for creating projects. I do not use subprojects but Omnifocus supports subprojects that can be either sequential or parallel. and you can mix the types in the parent project. I know there are several other task managers that support dependent or sequential tasks within a project.

[claremacrae]

@OogieM I'm glad that you have found a system that works for you.

[OogieM]

It works but it's not as seamless as an all Obsidian system would be.

[claremacrae]

It works but it's not as seamless as an all Obsidian system would be.

I fully understand.

I realise that this doesn't help, but there are enough other really popular requests of Tasks with more than 10 upvotes that are keeping me busy several full days a week, so I do not think this one is likely to happen any time soon.

[elight]

I'm using "project" tags to define related tasks. They're nested hashtags that start with #pr such that the project is #pr/<additional layers to contextualize and uniquely identify the project>, e.g. #pr/github/project1

I specify an identifier for each task (unique to the project) as a nested hashtag off of the project hashtag. Then I specify the identifiers of ancestor nodes: nodes that point to this node thusly:

#pr/github/project1/1
#pr/github/project1/2a/1
#pr/github/project1/2b/1
#pr/github/project1/3/2a/2b

The above specifies a branch and merge such that:

  1
 / \
2a 2b
 \ /
  3

I place pr tags exclusively at the beginning of tasks. This specification allows tasks to be sorted by description so long as the identifiers are consistently increasing per path flow in the project.

If one weee to treat, by default, each task in a project as blocking tasks further "down" the process in a given flow, a graph walk of nodes in a project should make it quite feasible to determine which tasks are available and which are not.

This format currently intentionally allows for directed cyclic graphs: a process that can point back to itself. I'm not sure if that's useful but when defining it I deliberately tried to keep this option open. For acyclic graphs, the "first" node should always be the node with no inputs and just an identifier and would never be blocked.

This approach does not allow for dependencies across tasks across projects. And a task is only a member of 0...1 project.

Thoughts? cc @claremacrae

[claremacrae]

Interesting. Thanks for sharing this.

[elight]

This also allows for task dependency/project flows like this:

[elight]

Code for visualization above is here

[elight]

Relies on CustomJS (thanks again, @claremacrae), Dataview as an injected dependency into my JS of my own (included), and a few lines of dataview in the markdown.

[claremacrae]

This is all in interesting workaround. I do think the original concept of task dependencies in this discussion is still valid. However, since Tasks was designed to store each task independently, for now using a workaround is a good idea.

[claremacrae]

A related request: #1179

[elight]

Related but a subset of this request.

[Cito]

Just a random thought: Maybe instead of tags, we could also use Obsidian block links for specifying task dependencies.

[claremacrae]

Interesting. I don't have a sense of how widely used block links are. As an aside, personally I feel they create a lot of clutter.

What was proposed in #1179 was quite simple.

[ArneNostitz]

I also would like to chip in here because I do a lot of cross referencing between tasks ... and was looking into faster ways of doing this - and more visual ways in showing this.

As I put tasks everywhere in my vault a consistent way of retrieving information is key. but organising tasks in a way of what to do first and what to do after would be amazing ... eg. an extensive way of linking tasks together, so a clear method of saying what i need to do next, what is dependent and cant be done (should be faded or not showing) etc.

i used todoist but they are lacking start-dates ... and also not really have a way of linking dependencies together

Currently I do use block-links (using the copy block link plugin for faster linking) and that "works" - but would definitely be better if it would have some integration in the Tasks plugin as a standard. Block linked tasks can be embedded - so the parent task is shown ... but this gets messy fast. also possible to cmd+hover to see dependent tasks - but there is no visual reference on first glance if the parent is done or not ... so that would be a great JS+CSS hack if that could be done (read status of parent task and place icon or other info tidbit into the current task - like a "#wait")

eg great features would be:

• create new dependent task (new tasks can only be done when this task is done)
• complete task with follow up task (automatically create new task that is dependendly linked to current task for follow up tasks)
• a color code or other way to see the dependencies in a query
• a gantt chart like view, or mindmap rolling these dependent tasks up

[ArneNostitz]

a good example of a way for dependent tasks could be viewed is "Taskheat" https://eyen.fr/taskheat/
looking at their csv export its quite simple: task (number 1); task (number 2, dependent on: task 1);

so if there could be a way to quickadd a link to another task this would become a great feature.

like the quickadd "due" and "recurring" it could offer a "depend" and then enter the blockquote for example. when using "short mode" this could be formatted as just a link symbol in Markdown. But in a mind-map view this could roll-up into a teaskheat like overview. (even if tasks are not in one md-file but spread out the whole vault)

I know - this is probably more complex than I think :-)

[schemar]

The architectural challenge with this is that Tasks currently has no way of identifying tasks. At the moment, tasks don’t have IDs or something like that. They are simply on a certain line in a certain file (more or less).

What Tasks would need for your request (and some other feature requests) to become feasible, would be (optional) IDs of tasks. For example provided as „block-link-IDs“ (^some-id).

Even then, in order to have a somewhat usable user experience, you would need to have some kind of pop up which let’s you select a task based on its description. That pop-up would then insert the block link/ID upon task selection.

All in all quite some effort. It’s very possible that other things have a better impact-over-effort ratio.

[ArneNostitz]

i do see the complex challenge and maybe i am the only one who looks for something like this to sort my brains ...

a visual representation of tasks in a mindmap like structure, where this could happen in a drag-and-drop way could be something. and maybe the implementation is somewhat possible in the future with the canvas.

but for now i simply do it with block embeds and probably at some point i realise that its not worth the effort in a system that is only accessable by me - and more needed in team structures in an online environment where tasks get distributed to other people and "waiting on" a task to complete is more of the essence.

block link ids do work, but are not pretty :)

[justrajdeep]

+1 for this request

[aubreyz]

Can I suggest a possible solution to this problem:

We could have a display filter that basically says "If tasks contain a #tag, only display the first instance of that tag".
This would then work with the sort order.

If we have 5 tasks each with #paint_ceiling

Then if we sort by due date, it will only display the one of the 5 with the oldest due date (if more than one it would show whichever would be displayed first in the output).

Alternatively we could have a secondary tag #1 to #100 and it would only display the task with #Paint_ceiling with the lowest found number (if any) that would otherwise be displayed given other search terms.

Or some variant of that.

[schemar]

You can already achieve this, right? Filter a query by that tag, sort it, and limit it.

This could be a viable workaround for the time being 🤔

[claremacrae]

Sounds good.

[claremacrae]

Alternatively we could have a secondary tag #1 to #100 and it would only display the task with #Paint_ceiling with the lowest found number (if any) that would otherwise be displayed given other search terms.

Tasks does currently recognise tags with only numbers in - but it should not, as Obsidian does not.
#929

Whenever I release Tasks 2.0 - at some indeterminate point in the future - Tasks will be consistent with Obsidian and not treat #1234 as a tag.

I therefore recommend not setting up any schemes now that depend on pure-number tags, as they will only need to be reworked later. (Plus, Obsidian won't search on them and link to other instances of the tag anyway.)

[aubreyz]

Yes but that would only show one task. I guess what would be good is to show the first-needed of every task group

So what you want to do is to be able to limit it to 1, but if one groups tasks by (whatever) it would only show the first in each group, not just one task altogether.

[claremacrae]

To avoid disappointment by raising false hopes, I've added 'status: not planned' on this.

If you really need to manage dependent tasks, I recommend finding another plugin or system.

[claremacrae]

See also #572 - which is being closed as a duplicate of this.

[claremacrae]

Removed the 'not-planned' label - as this is starting to be thought about...

[claremacrae]

Please don't repost the whole discussion here. Thanks.

[Genei180]

@claremacrae for your Key message, there is another Plugin "Obsidian_to_Anki" which creates flashcards from your Vault.
It needs to Connect the Database ID from Anki with Obsidian too.

It does it in the following way:

# Example
Q: Question Card
A: Answer Card
<!--ID: 1695720387138-->

With an ID in a Comment. The Comment can't be seen in Reading Mode
This Could maybe be an Option to Achieve this Behavior.

Additional, with Hacktoberfest Coming up, would there be an Option to Participate in the Development of this?
And if yes, where would the best way to get started be?

I am myself desperately in need of a Task Plugin which allows for Dependencies and maybe even Visualization, like in the thread above.
But i am not really a fan of the Tag Syntaxes Look and Feel, as it adds a lot of Clutter & thinking.

Thanks for your Time and Help.

[claremacrae]

Hi @Genei180, thanks for the message.

@claremacrae for your Key message, there is another Plugin "Obsidian_to_Anki" which creates flashcards from your Vault. It needs to Connect the Database ID from Anki with Obsidian too.

It does it in the following way:

# Example
Q: Question Card
A: Answer Card
<!--ID: 1695720387138-->

With an ID in a Comment. The Comment can't be seen in Reading Mode This Could maybe be an Option to Achieve this Behavior.

No, I don't think so. We have already settled on the mechanism we will use, and the above is much more complicated - both for users and developers. (Tasks treats every task as a single line.)

Additional, with Hacktoberfest Coming up, would there be an Option to Participate in the Development of this?

Thanks for the offer, but no, having two people working on the same thing at the same time couldn't be effective.

Also, unfortunately I have not heard positive results from project owners about the quality of contributions they have received from previous Hacktoberfests, so I'm disinclined to support it for that reason too.

And if yes, where would the best way to get started be?

For general reference, we have the Tasks Contributing Guide.

I am myself desperately in need of a Task Plugin which allows for Dependencies and maybe even Visualization, like in the thread above. But i am not really a fan of the Tag Syntaxes Look and Feel, as it adds a lot of Clutter & thinking.

This is off-topic for this issue, but I don't understand what you mean by 'Tag Syntaxes' - nothing about Tasks requires users to use tags - maybe you incorrectly believe that a global filter is required in Tasks? It isn't.

Thanks for your Time and Help.

It's a pleasure...

[Genei180]

No, I don't think so. We have already settled on the mechanism we will use, and the above is much more complicated - both for users and developers. (Tasks treats every task as a single line.)

I understand that the decision is already made, it was just a suggestion, and the Example above could have been adapted to fit one line.

Thanks for the offer, but no, having two people working on the same thing at the same time couldn't be effective.

Understandable, if I still can help out somehow, let me know.

Also, unfortunately I have not heard positive results from project owners about the quality of contributions they have received from previous Hacktoberfests, so I'm disinclined to support it for that reason too.

That's unfortunate to hear, but I'm sure there were some quality Contributions along too.
But I can totally relate that managing such a Project, especially if people don't communicate together on the Goal or the way its implemented, can be a Pain. That's why i asked first.

This is off-topic for this issue, but I don't understand what you mean by 'Tag Syntaxes' - nothing about Tasks requires users to use tags - maybe you incorrectly believe that a global filter is required in Tasks? It isn't.

What i was referencing was this: #463 (comment)
in an earlier Discussion thread. But Thanks for Clarifying a Potential Mistake.

But this brings me to a Potential Use Case/Feature Request for the Addition of Dependencies.
Again I understand that the decision is already made, and again it is just a suggestion.
Having Dependencies is nice, but what makes it really Useful is capturing at a Glance where the Holdup is.
Therefore, Visualization like in the Above Comment is at least in my World Desirable.
How it will be done is another Question, in a separate Plugin? or in the Obsidian Canvas Plugin? or in the Node view?, Or not at all? Or as Custom (Dataview) Script? are all options which could be considered.

Additionally, it makes sense in my World to add the Information of the Type of Dependency to the Dependency.
Types could be: Finish to Start, Finish to Finish, Start to Start or Start to Finish (See Types of Dependency)
This allows for even Better Visualization of Hick ups and Priorities. Maybe even Auto Generation of Flow Charts / Gantt Charts could be Possible with that Information.

I know this is a really Advanced Use Case but in my World they go along, and I can Totally Understand when the Work for it is not justified or in the Scope of the Project.
But I wanted to alteast State it, so it's documented and maybe thought about.
It potentially may even be out of the Scope/Misuse of Obsidian, but that's a Way how I currently would like to use it.

Unfortunately, I don't have access to the Discord Thread you mentioned earlier.
But I would be interested in your current Solution, and maybe joining the Discussion if I am allowed too.
If not, I understand that too.

Again, thanks for your Time and patience.
(you probably just gave me the fastest Reply I ever had on GitHub.)

[claremacrae]

Thanks for the suggestions and information, @Genei180.

[Gnossos]

Hello. Thanks for the stimulating discussion. I have four thoughts to contribute:

• This is indeed a very useful and much-needed enhancement.
• Besides strict task dependencies, it probably could also be used to relate different levels of goals (or anything analogous). For example, some versions of the Most Important Task (MIT) method call for making annual, monthly, weekly, and daily goals; then at least some of a day's MITs are chosen because they contribute to the week's goals, which in turn are prioritized because they contribute to the month's goals, etc. Being able to establish such a hierarchy of tasks would be very useful.
• In addition (and this may belong in a separate plugin), would be the ability to apply PERT & CPM methods to project planning. Fortunately, there is a R package that does this, and like most R packages it's FOSS. So, both user documentation and source code are available, and this means such an extension wouldn't need to reinvent the wheel entirely. There may also be benefits to coding the data structure in a compatible way.
• Which brings up another thought. If Obsidian can have extensions to third-party software, such as the five Zotero plugins currently available, it's not far fetched to imagine a R Project plugin. The R Project already has R Markdown and a project structure that's not too dissimilar from Obsidian's vaults. The user interface for R is also pretty much just text based. Just sayin ....

[claremacrae]

Dear folks who are interested in having task dependencies in the Tasks plugin...

Suppose that in some brave new world, tasks can now have:

• an ID field, with emoji 🆔
• and a DependsOn field, with emoji ⤵️

For example, you might have a set of tasks like this:

- [ ] not blocking
- [ ] parent ⤵️ 12345
- [ ] child 🆔 12345
- [ ] child without parent 🆔 23456

Or this set, where there is a circular dependency.

- [ ] circular dependency test - 1 ⤵️ 2 🆔 1
- [ ] circular dependency test - 2 ⤵️ 3 🆔 2
- [ ] circular dependency test - 3 ⤵️ 1 🆔 3

Now imagine you are writing a Tasks query block, and you want to use the dependency information above.

What kinds of filters would you like to have, and why? And how do you want those filters to behave?

Consider cases like where one task depends on several others. What if some of the child tasks were completed, and some not?

And what if task 1 depended on 2 which depended on 3 which depended on 4.... And 2 and 3 were DONE, but 4 was not. How should searches work then?

Thanks in advance.

[OogieM]

First off the terminology is confusing to me. A DependsOn field, with emoji ⤵️ should only be in the children not the parent IMO. So I'd actually reverse where the emoji's are located. So the parent would have the 🆔 and then all the children that depend on it would have the ⤵️

To me you can't do the child task until the parents are done. I see dependencies as primarily sequential. If you keep it the way you are describing then call the field something else because the parent does not depend on the child, the child should depend on the parent.

In my way of thinking you set an ID on the parent. Then each child has a depends on with that ID so I'd see the children as potentially have ing both an ID field and a depends on field.

So in my query I typically want to see the parent task if not done. Then work down the tree. If the parent task is not done then all children that depend on the parent are not available to be seen unless you specifically say ALL tasks or something. Only when a parent task is checked done do its children become availbale. There should be a way to see all the tasks ncluding the blocked ones.

If a parent has several children that are dependent on it being done then once the parent task is done the available children should be seen. If some of those children are also parents then their children are not seen until they are done and so on.

So In my mind I'd like to set up thesethese sorts of cases:

• not blocking
• child without parent 🆔 23456 is the same as a non sequential task
• Parent task -1 🆔 1
• Child task - 2 🆔 2 ⤵️ 1
• Child task - 3 🆔 3 ⤵️ 1
• grandChild task - 4 🆔 4 ⤵️ 3

When parent ID 1 is done BOTH 2 and 3 become available but you won't see the grandchild task id 4 until its parent, child 3 is completed

The default should be tasks without 🆔 fields and they are considered stand alone parents. Only once you need to set up a dependency should you require the 🆔 and ⤵️ on characteristics.

Or in a more real world case based on my world. I just had to write this all out as I'm training a new farm hand.
The project is Sheep in from Pastures

• Sort sheep into groups into corrals 🆔1
• Move mineral feeders to corrals ⤵️1
• Move water tanks into the corrals ⤵️1
• Pull all electric fences from pastures 🆔2 ⤵️1
• Stretch out all electric fences and repair them 🆔3 ⤵️2
• Put a string on the end of every single electric fence 🆔4 ⤵️3
• Use woolevator to move electric fences to shop building 2nd floor ⤵️4
• Store water hoses in the garage ⤵️1

[jkbhagatio]

Hi @claremacrae , just wanted to say that @OogieM 's suggestion here makes a lot of sense to me!

[Genei180]

I just noted Obsidian has a Feature named Block Links:
https://help.obsidian.md/Linking+notes+and+files/Internal+links#Link+to+a+block+in+a+note
Sadly, is just Obsidian Specific.
It looks a lot Similar to the ID Syntax Chosen.

If the Whole task became a Mentionable, it could be more easily Referenced in Native Text in Obsidian, via Suggestions.
As Remembering Every Number to Every Task could become quite Difficult.

I Like the Suggestion of @OogieM regarding the Layout of the Fields.

Because

So in my query I typically want to see the parent task if not done. Then work down the tree. If the parent task is not done then all children that depend on the parent are not available to be seen unless you specifically say ALL tasks or something. Only when a parent task is checked done do its children become availbale. There should be a way to see all the tasks including the blocked ones.

for me, it's Actually the other way around for default.
I would like to see the parents first, when all Child Components of it are checked.
The Dependency Type Dictates the Behavior which is expected.
For those not wanting to specify it, a Default Behavior could be Set in the Settings.

@OogieM is A -FS-> B Behavior, the other (mine) is B-FS->A.
When B is the Child of A.

And what if task 1 depended on 2 which depended on 3 which depended on 4.... And 2 and 3 were DONE, but 4 was not. How should searches work then?

1(A) -Depends On-> 2(B) -Depends On-> 3 -Depends On-> 4

Depends on the Type of Dependency of those Nodes Mentioned.
But by Terminology in my Understanding "depends on": determined by conditions or circumstances that follow
See Discussion here: Meaning of A depends on B

In project management (and lots of engineering), B is the prerequisite for A, in that it must come first. B does not necessarily know or care about A.

(Be Aware in the Wikipedia Link Mentioned A & B are Switched by Meaning which makes it a Hell of a lot Confusing, i tried to keep it Easier to Understand and Write it out in the right way)
Which in my Eyes should be an 2(B) -FS-> 1(A).
FS := Finish to Start (activity B must finish before activity A can begin)

So, by my Terminology, 1 (A) can Only be started when 2 (B) is finished.
So the Example given by you, described by these Words, is rather unintuitive and should not be Possible in this way.
As 2 and 3 Should only be Finishable when 4 is finished.
This opens the Discussion of the Program should then Assume 4 is Finished, or Should 4 at least be displayed under 1.
I'm for the second, as hiding unfinished Tasks is not a good Behavior in my Opinion.

The Situation you Describe can arise if
4 -FS-> 1
3 -FS-> 1
2 -FS-> 1

Which should translate to 1 is Dependent on 2, 3 and 4 in my Understanding.

Please correct me if I'm wrong, its rather difficult too Wrap my Head around and i could easily have something wrong.
Hope I'm not too late to the Discussion.

[aubreyz]

I don't ever mark tasks as completed I just delete them or defer them. So the other question is what happens when one is deleted.

I think the key is to keep it as simple as possible. Completions and deletions (and manual changes to the ID number) do absolutely nothing to any other tasks - anything else has potential to be extraordinarily confusing and unstable.

Consider the purpose of the whole thing. In my view the main purpose of dependency is to NOT_SHOW dependent tasks unless the main task is shown. In that model it could be many to many or one to one or other combinations. Many to many seems best (tasks could be subordinate to many main tasks and visa versa). If that is the purpose and the model then there would be only one filter:

"Only show dependent tasks if the any|all master classes are shown (based on whatever other rules are set)"

Then I wouldn't worry about grand grand grand children - if the user wants to set up such a complex arrangement that is up to them

Why not leverage existing tag system for this #floorlaid #iffloorlaid or something like that

[OogieM]

In my view the purpose of dependancy is to be able to filter tasks based on what is possible to work on. So don't show things until a taske that must be done first is finished.

I never delete tasks at all. They all stay but are completed. That way I have a record of work done and that's critical for billing and also writing project status reports. I also make big use of the completed dates in my queries.

The reason not to use tags is that it's FAR more difficult to set and reset tags when something is done and complex projects with trees of dependencies are how I work all the time.

PS I don't think I've ever defered a task either. They stay avaialble until done. They might have start and due dates but I very rarely if ever change them.

[claremacrae]

One of the things I learned early on my 18 month tenure of looking after Tasks is that it's impossible to predict every way in which people use the plugin, and manage their tasks.

So it's absolutely fine that aubreyz deletes completed tasks, and also it's fine that OogieM doesn't.

[claremacrae]

In my view the purpose of dependancy is to be able to filter tasks based on what is possible to work on. So don't show things until a taske that must be done first is finished.

Do you think you might ever want to search for tasks that cannot be worked on because of a dependency, just to do a review, for example - or to see if there's anything critical coming up that needs its ingredient tasks to be done as a priority?

[OogieM]

Yes, that's when I want to see the entire tree, the show all tasks option I described in my response. It's not that common for me though.

[Genei180]

I don't ever mark tasks as completed I just delete them or defer them. So the other question is what happens when one is deleted.

That's an Interesting Question.
The Deletion Event by itself, (when not tied to the Checkbox Checked Event) could be rather Difficult to get a note off.
If you want to use Dependencys and have for Example A depends on B and B depends on C.
What happens when you delete B?
(Our Problems are described by Node or Graph Theorie btw.)
And there are multiple Solutions.

But probably the Easiest is to Color the Task A Red and Notify the User that a Dependencie is missing/Unresolvable.
Fixing it is in the Hand of the User.

Automating it in some way will probably Result in unexpected Behavior for atleast some Users.

I think the key is to keep it as simple as possible. Completions and deletions (and manual changes to the ID number) do absolutely nothing to any other tasks - anything else has potential to be extraordinarily confusing and unstable.

That's right, KISS (Keep it Simple, Stupid) is always a good Idea.
Deletions and Changes should be solved by the Idea Mentioned above.

But a Change should be, in my Opinion, always be Automated too all References, as this Behavior should be Expected by all Users.
And Manually Resolving it should be Avoidable.

Consider the purpose of the whole thing. In my view the main purpose of dependency is to NOT_SHOW dependent tasks unless the main task is shown. In that model it could be many to many or one to one or other combinations. Many to many seems best (tasks could be subordinate to many main tasks and visa versa). If that is the purpose and the model then there would be only one filter:

"Only show dependent tasks if the any|all master classes are shown (based on whatever other rules are set)"

Then I wouldn't worry about grand grand grand children - if the user wants to set up such a complex arrangement that is up to them

Other Use Case could be, for me atleast:

• Only Show Tasks if they have no dependency, so all Tasks i see, are Actually Workable and not Blocked by another Task

This is quite the Opposite of yours.
In my understanding this means in Your Use Case, you either see all tasks (including their Childs) or none?
Please correct me if i misinterpreted it.

Why not leverage existing tag system for this #floorlaid #iffloorlaid or something like that

Good Question.
There is this Existing System: Comment here
Which even has a Visualization for it. Here
If you know more please let me know.

The Main Limitation with this Approach in my Understanding is it creates Nodes not the Dependencies (The Paths Connecting the Nodes)
Changing the Order causes a lot of trouble/manual Updates, which would not be the case if you could just change the links/dependencies.
Which falls into your Question what happens when you Delete/Edit a node.
And with this Tag Setup, both Operations cause trouble.
Even more, as a Deletion is not just connected to the tasks linked to it, it is connected to all tasks that are lower in Hierarchy of that node (Grand Grand Grand Children For example) as they have the Name of the Parent Node in their Tag.
Another Problem is inserting a new Node.
Additionally, Tags could become quite fast, really long and Unreadable, the Bigger the Project.

Some of these Problems could be worked around with a Search and Replace Operation, which would make this System Probably work without a Plugin in a Standalone Text File, which would fit one Goal of Obsidian.
But requires more Steps too maintain it.

Sorting Tasks and filtering them in the already Existing Tasks/Dataview Views could become quite Difficult and is Probably why at least I would prefer it Implemented in the Plugin System.

[aubreyz]

What we have here in essence is two radically different meanings of dependency

a) Don't show any tasks about painting the walls (choosing colors, buying paint) until the roof building tasks (lay beams, fit tiles) are "finished"

b) Don't show any tasks about painting the walls until the painting wall master task is somehow started (or is visible)

(a) doesn't work for me because I have no concept of "finished". And even if I did use task completions how would that work? The roof building task would not be finished until ALL the various roof building tasks were finished. There would not be a "Roof is built" task because that is not a task at all, it is a goal which is dependent on the roofing tasks.

[claremacrae]

What we have here in essence is two radically different meanings of dependency

I thought that the Types of Dependency article mentioned recently by @Genei180 in this comment was interesting in this regard... And may possibly explain the differing interpretations in this discussion????

Nevertheless, just to set expectations...

As Tasks is free software written in volunteer time, having read the replies here and requests elsewhere, and based on our own personal uses of Tasks, we will pick a single approach to release first, and write the documentation in a way that the behaviour will be clear, and people can choose to adopt it for their own uses or not, as they see fit...

So all feedback and suggestions are greatly appreciated, and will be considered.

I would love to hear from a wider variety of people, out of the 12 other people that have interacted with this discussion so far...

[aubreyz]

I think the semantic/practical difficulty in that link is that there is a confusion between tasks and other types of nodes or events which are not really tasks at all. In this particular package all we have are tasks. These tasks are not like phases in a Gantt chart.

For example they they give:
Vaccination of baby has to be done not immediately after birth, but within certain time

Problem is that "Have Given birth to the baby" is not a task at all really. It is a node in time. So unless you create artificial tasks "I have now given birth", or "I deem the roof is now completed given sufficient of the roof completion tasks are done" I can't get my head around how this fits with atomic singular tasks which are being processed ...

[OogieM]

(a) doesn't work for me because I have no concept of "finished". And even if I did use task completions how would that work?

If you never finish a task then I don't see how dependencies even matter. I guess I've spent too many decades using more traditional project and task management systems to not have the concept of a task being done. Even if it is something that happens again on some regular schedule there is still the concept of this instance being finished or done.

The way I handle your case of b is for projects like that the top or parent tasks all have a start date and I don't see them until that start date arrives and then the dependency tree works.

So for me what i call dependency is the natural one of finish to start from that linked article.

If I look at previous task managers the one I used longest before Obsidian was Omnifocus. In it the top level is a project and there are 2 kinds of them, one is sequential (i.e. with dependencies ) and the other is parallel. The actions or tasks are always under the umbrella of a project. It also had the idea of a top project being parallel but pieces could have sequential subprojects.

My Obsidian implementation is that anything that takes more than one action to complete is a project and projects have a single obsidian note in which all the actions are placed. An action is a single task I can complete. Some may take multiple timeslots to finish but they are discrete things that are done at some point. My top master note also has references to all the documents, meetings, people, other resources etc. that I need to be aware of so the project note is my master dashboard. I've implemented dependencies by not putting the tasks keyword into tasks that I can't do and by trying to look at the projects daily to update what is or is not a task. It's a bit tedious to do but has the advantage that all my project support material is already in Obsidian so it's only one app to work in.

I too would like to hear how other people view task dependencies and how they use the tssks plug-in to handle their work.

[OogieM]

I guess I DO create "artificial tasks" For my vaccination project the project note is Lamb Vaccinations. I have what particular drugs we use in there and the ages at which they can be done. So for example one of them is Covexin 8 and it has to be done when the lambs are 8-10 weeks old and repeated 3 weeks later. I know when lambs are expected based on when the rams got put in the breeding pens but until the ewes give birth I don't know when lamb vaccines will start. There are dependencies and each year the dates are different based on breeding dates and actual gestation periods of the individuals involved.

The first task in that project is set to start in April well before we ever expect lambs and it's to buy vaccine. I have a waiting for context in my task system and so I have a task that is Waiting for primary lambing to start in that project. Once lambing commences I can set the dates for the first vaccine with start and due by dates. Only after the first shot can we even think about the second one and its window is much tighter, not a 2 week window but a 1 week and ideally a 1 day window so as the project moves forward the dates become more constrained. We often have 3 batches of lambs and each batch is grouped based on the age of the youngest lamb. We also have the added constraint of weather because you can't vaccinate wet sheep so I slip and move the dates based on when we really do it.

Which brings me to another use case:
I'd love to be able to set a start date of a dependent task based on the completion date of the parent task. So if my task is Give early lambs their initial Covexin 8 shot and it starts on say July 2 with a due by date of July 16 then whatever day I finish that task the next one which is Give early lambs their second Covexin 8 shot gets triggered to start 3 weeks after I finish the parent task and the due date is automatically calculated based on ththe actual start date. Now I think tht is beyond what is planned but it would be really useful to me.

[claremacrae]

Thanks for the example...

I'd love to be able to set a start date of a dependent task based on the completion date of the parent task.

Yes, you're right, it's definitely way outside the scope of this work...

You're welcome to submit a feature request in 'Issues' - and if you do, please give as much information as possible about it could possibly work. Like what emojis or other info you would provide on a task line in order for it to work...

(My reasoning is that you understand the feature, so are going to be better placed to what info it needs, and what that might look like... And if you aren't able to say how it will work, it's unlikely anybody else will...)

[claremacrae]

Thanks for the comments here folks.

Just to set expectations, it's clear to me that no single implementation of dependencies is going to satisfy everybody here.

By aiming for perfection and trying to satisfy everyone, we will never release anything... So I will release when I am happy that we can satisfy at least some user needs.

[stasmarkin]

First of all, thank you for your efforts in this plugin, this is a really great tool!

I've read all the discussion and i just want to add something.
In my opinion (I might be totally wrong), there is no need to create another all-in-one CRM and trying handle all types of task dependencies. Since obsidian is a note taking app (not a task tracker by it's nature), the task management plugin should be focused on parsing the natural way people make notes.

For example, if you have a paper and a pencil, there is no way you will add "ID::123 depsOnSF::124" to you notes. You will naturally build a list with some tabulation on each element just to build an hierarchy. You won't explicitly write an hierarchy type (which one if higher and what does that mean), because you will know that does that mean in your personal sheet of paper.

I believe, you will fulfil 90% people needs with simple walking on naturally built list. All other stuff they will do with tags or js code. I suggest that API for convenient navagation on tasks:

Task.next(): Task? (sorry, I don't know js or ts, so next() is a function on Task object, that returns another Task or null)
Task.prev(): Task?
Task.parent(): Task?
Task.children(): List (task array, that might be empty)

So for a simple and natural tasks list:

 - [ ] Task1
	 - [ ] Task2
		 - [ ] Task3
		 - [ ] Task4
	 - [ ] Task5

Task1.next() == null
Task1.prev() == null
Task1.parent() == null
Task1.children() == [Task2, Task5]

Task2.next() == Task5
Task1.prev() == null
Task1.parent() == Task1
Task1.children() == [Task3, Task4]

and so on

[Genei180]

In my opinion (I might be totally wrong), there is no need to create another all-in-one CRM and trying handle all types of task dependencies. Since obsidian is a note taking app (not a task tracker by it's nature), the task management plugin should be focused on parsing the natural way people make notes.

It's your Opinion, and there should not be a Right and Wrong to an Opinion. :)

NO need to create another all-in-one CRM and trying handle all types of task dependencies

CRM stands to my Knowledge for “Customer Relationship Management”.
Too my Understanding, Obsidian is a PKM (Personal knowledge management).
Do i have a need for a CRM in Obsidian? No
Do i have a need too Track my Personal Knowledge of Tasks that i have too do? Yes, i do.
Do i have so many Interconnected Tasks and just want to Find Tasks which I can do now too, don't lose my Overview? Yes, please.

the task management plugin should be focused on parsing the natural way people make notes.

True, if it's not Easy to Use and Write and feels Naturally, than it will Probably not get Used.

I believe, you will fulfil 90% people needs with simple walking on naturally built list.

The Problem for me arises, what is when I want to go with the Natural Flow of my Project and want to define tasks still Everywhere where they occur?
For Example, in the Daily Note, or in a Project Note for it.
Or I have Multiple Projects and one project “Building a 3D Printer” depends on the Project “Build my Workshop” etc…
How do I define these Dependencies? That's for me where simple Bullet List Styles fail and I start to Lose my Overview when still all tasks get displayed via a Query.
Because I made like 1000 Thoughts via Reverse Planning How I Want to get to the Goal of Building a 3D Printer and a 1000 Thoughts on how I want too Layout my Workshop.
Because i Note them when they Pop Into my Head, which is Exactly what is Obsidian for.

Is Task Management PKM? Depends on the User too my Knowledge.
So is there "NO need" for it? Wouldn't Say so, in my Opinion.

All other stuff they will do with tags or js code.

Too my Knowledge, sadly, currently it is not easily doable with Tags and JS Code. At least too My Knowledge.
If somebody knows a Way to Manage Dependencies Naturally with JS or Tags, please let me know.

I suggest that API for convenient navagation on tasks:

Could you elaborate further what the API should do?
And how it solves the Problem of the Missing Feature Task Dependencies?
To Solve Previous mentioned Problems?

But I Already Wondered if It's Maybe not Easier to make a Plugin for Taskwarrior.
I understand this Plugin was Probably Born to make easy use of Tasks.
It got probably to a Big Popularity because of it, but it seems like now we try to Reinvent the Wheel with it.
Software with these Feature Set Already Exists.

One of the Reasons to Adapt this Plugin for it, is that (I believe at least) Task warrior Plugin can probably not be Run on Mobile Devices later on via Obsidians Plugin System.

[aubreyz]

Kind of in response to the background of the last comment -- can I make another alternative suggestion.

If several tasks exist in a note, then if the search is one filtered by dependency - show only the first task in any note (or under any individual header).
Isn't that dependency in a simple nutshell?

[stasmarkin]

with my suggestion you may write a filter like that:
filter by function task.prev() == null || task.prev().isDone()

You will get first undone task in one note (assuming that you will be checking out tasks one by one, else you will need somw recurring function)

[claremacrae]

Thanks for the comments here folks.

Just to set expectations, it's clear to me that no single implementation of dependencies is going to satisfy everybody here.

By aiming for perfection and trying to satisfy everyone, we will never release anything... So I will release when I am happy that we can satisfy at least some user needs.

Just to say that I'm locking the discussion here for now.

It is not feasible for me to keep up with and analyse the volume of comments at this rate, and as such, I don't want people to spend their time crafting replies that we will not use - and that risk becoming a bit personal.

[claremacrae]

The first release of Tasks Dependencies is now out:
https://github.com/obsidian-tasks-group/obsidian-tasks/releases/tag/6.1.0

Enjoy....