Ability to reference other tasks

[ChargingBulle]

Hi. Sometimes I create a task for the far future and I'm not sure if in this "far future" I remember what's it all about.
I usually annotate my tasks like this:

Date                   Modification
2018-09-20 08:03:18    Annotation of 'ref f41f3783-ca24-46ed-8f30-058330cb261d' added.
2018-09-20 08:03:27    Annotation of 'ref d77308d4-0c34-4615-aa4b-c7720997c7a7' added.

It would be way cooler if taskwarrior had a native way of linking tasks. Simiar to JIRA:

Personally I don't need a concrete relationship parameter (child/causedby/...).

[scottkosty]

Have you considered using a https://taskwarrior.org/docs/udas.html?

[pbeckingham]

We have considered arbitrary task linking. It turns out to be a lot more complex than anyone realizes. It's not likely to be implemented.

[ChargingBulle]

is there doc and/or mail on the archive on why this is so complicated?
right now I annotate with ref <uuid> when I want to reference other tasks. It works "okay" but leaves much room for improvement (e. g. a UUID in itself says nothing, is not bidirectional and can't be copied without being considered string substraction...)

[ghost]

Possible duplicate of #141

[ChargingBulle]

@sampablokuper it seems to me that you are right. Ticket #141 strikes a very close vein.
I will read up on that and either make this ticket more precise or close this as duplicate.

---

We have considered arbitrary task linking. It turns out to be a lot more complex than anyone realizes. It's not likely to be implemented.

I found a write up on this here: #141 (comment)

[ChargingBulle]

This is our killer feature. Solving all this and coming up with a good linkage plan would be a major and dramatic enhancement to task, and would satisfy the bulk of all the (big) feature requests ever made. We could identify critical path. We could have estimates and estimated completion. We could make a really good "next" algorithm without the need for heuristics. We could have reports with natural groupings. The list goes on...

_{Paul Beckingham on 2009-12-23T11:08:09Z}

So basically

• yes it's a duplicate
• yes this is a great feature
• yes it's perfectly doable
• but, someone has to think this through since it would be a very fundamental addition

I call this is a case for a TW RFC

---

closed as duplicate of #141