Hi Kirill -

I'd place the descendant due date as described, then a plus-sign character, followed by the ASAP value in italics.

Happy to mock it up if it would be helpful, too.

Cheers!

Hello Peter,

How would you handle the case when a parent has both "ASAP" children and children with a specific due? How would it be shown?

Best,

If it makes this feature more worthy of implementation, my use case is more generalized. I call my idea "deep tags" because they are an extension of TaskPaper tags, where a due date would be marked with a tag like "@due(2019-08-08)".

I wish an item could have an additional due date which is based on the value of child items as described others here. I will call this tag "#due" using a '#' sign to indicate it's a deep tag. However, it could be called anything, like "@effectiveDue" or "nextDue".

This concept could be extended to other deep tags: #count, #min, #max, #sum, #avg, etc... You could even have user-defined deep tags by running a script that looks like deepTagName(defaultValue, item, childItems[]){ CODE}.

Besides the due date use case discussed by others, here's a use case for #count. Your sales pipeline has many stages and you tag where each prospect is in the pipeline (like: "idea", "gather contact info", "touch", "demo", "won", "lost".) The deep tags like #count(idea), #count(touch), #count(won) would automatically count how many are at each stage, which is valuable information.

Hi, Kirill!

I think the ability to determine more pertinent information about an item and its children at a glance would be superior to filtering. The use case, IMO, is different.

For example, the filtered view is solid for honing focusing on items with a due date, sure. But it also expands the entirety of the list for items with a due date, pushing items off screen, and changing the visual landscape. I.e., it causes the content to "jump". That's fine for its purpose, but not conducive to an on-load understanding of where I might need to pay attention.

With parent items displaying the date of the nearest-due child (perhaps adjacent to its own due date), I'm able to instantly see that I have nested items due even if that item's branch is not expanded.

I see this looking like this:
- A collapsed parent item *without* its own due date displays the due date of the nearest-due child in the same fashion as a regular due date, with the addition that the font is italicized.
- A collapsed parent item *with* its own due date displays it's own due date as is currently done, and also displays the due date of the nearest-due child in the same fashion as a regular due date, with the addition that the font is italicized, and it sits just next in reading order from the parent's due date.
- The display of the due date of the nearest-due child should be considered for one of at least these two places: 1) On the most-descendant collapsed parent item, or 2) the top-level item containing the collapsed item with a due date.

Cheers~

Hello Peter,

Sorry, not yet. This request is quite valid, but I suppose, its usecase could be better covered by filtering the list with "due:any" filter. Am I wrong?

Thanks,

Kirill, any update on this? In your message from 2012, you expressed interest in a presentation of a use case. Do you need one?

I would also like to be able to sort by this date. So a long-term parent task like "read book by next week" can be "bumped up" in the sort order by adding a child task like "read chapter 1 by tomorrow."

This is a great idea- being able to see Task (overall due) (soonest child task due) and then have it so that when the child's date is clicked on it expands the tree and selects the child (or on hover could just reveal child task title).

Once I have some votes I'll support this!

Thanks for the idea, may be we'll find a decent presentation for such cases.