List items that are due in number of days specified in the tiddler field

#1

Hi All,

first time here so sorry if there’s something wrong :slight_smile:

I have a Wiki that’s doing GTD stuff. Some tasks have field “due”. Now, in my Next Actions I want to list items days:due[x]. I can do this fine by directly putting the number instead of X.
But… I want that every task could control how many days before due it should appear in my next items. E.g. by default tasks with due are listed in Next Items if they are due in 7 days, but Task “A” needs to be listed if it’s due in 10 days. So I add a field “start” in “A” tiddler and put a value of 10.

My filter macro to list only tasks that have field “start” and their value is due within their defined value in field start:

\define rs-next-projects-subitems-start()
[all[tiddlers]has[due]tag{!!title}days:due{!!start}]
\end

And it just doesn’t work.
It works fine if I add this filter to the task itself as

<$list filter="[all[current]has[due]tag{!!title}days:due{!!start}]"/>

it works fine, either listing it’s own title or not, depending on it’s “start” field value.

Any clue why this type of expression does not work when filtering with all[tiddlers] outside of the filtered tiddler?

Thanks in advance!

1 Like
#2

When you use {!!title} and {!!start} within a filter, they refer to fields in the <<currentTiddler>>, which is the tiddler that contains the filter syntax. Thus, it works as intended when embedded directly in the task tiddler itself.

However, in your macro definition, you want the {!!title} and {!!start} values to refer to fields in each of the tiddlers matched by [all[tiddlers]]. To accomplish this, you can use the :filter prefix, like this:

\define rs-next-projects-subitems-start()
[all[tiddlers]has[due]] :filter[tag{!!title}days:due{!!start}]
\end

This works because within the :filter[...] syntax, the value of <currentTiddler> is automatically modified to refer to each matching tiddler, as generated by the preceding filter run (i.e., each tiddler that has a due field).
You should then be able to use the following syntax within the task itself:

<$list filter=<<rs-next-projects-subitems-start>>/>

Note that in order to reference the <<rs-next-projects-subitems-start>> macro, you will need to tag the tiddler in which the macro is defined with “$:/tags/Macro”, so that the macro is globally defined.

enjoy,
-e

2 Likes
#3

Hello Eric,

thanks a lot for your reply. I was thinking that it might be related to the currentTiddler definition inside the filter.

But the strange thing is that [tag{!!title}] works fine without the :filter prefix, so I thought the same should be with other fields as well… Do system fields behave differently within this type of filter notation than custom fields?

Thanks again!

Edit:
And that’s exactly what happened:
The proposed solution:

\define rs-next-projects-subitems-start()
[all[tiddlers]has[due]] :filter[tag{!!title}days:due{!!start}]
\end

did not work. I had to take tag{!!title} out of :filter, then it started to work as intended.

Anyway, thanks for the solution using the :filter!

#4

I had mis-interpreted what your filter was supposed to do. You are correct, that the tag{!!title} syntax belongs in the first filter run. Thus:

\define rs-next-projects-subitems-start()
[all[tiddlers]tag{!!title}has[due]] :filter[days:due{!!start}]
\end

-e

1 Like
#5

Oddly I think there is in some ways a benefit to doing the opposite to what you ask with reoccurring items. Imagine that every time you do something you stamp it with a redone-date of now. In some ways this is the only fact you need, and it also serves to indicate when it is done today, and last done.

  • if for example it is a weekly event, list only tiddlers that were done older than a week (7 days)
  • This allows you to see when you did not do your weekly item for three weeks ago, because it only gets stamps when you do it.
  • This ensures your weekly task remains due indefinitely, wether you did it or not.
  • You can even future date it to any arbitrary date.

Now you write a list widget that can list those items with a redone-date of today, before today or one day in the future (or any arbitrary period 14 days) .

If you wish to break this down further to weekly, monthly, every blue moon, etc… what you change is not the tiddler but the list, and to identify a weekly event as an example you may indicate it’s weekly period in one of three ways; that you different lists make use of to limit the listed tiddlers.

  • tag it weekly
  • have a weekly-date field instead
    • The advantage here is you could give the same tiddler both monthly-date and annual-date
    • you could also future date weekly-date a month into the future and once the month passes it occurs weekly.
  • or have a period field containing weekly, or a list field containing more than one relevant period.

Now what I propose may or may not seem brilliant but it goes a lot further as it provides a framework on which to do much more, for example;

  • you are about to travel overseas for a month, or take a vacation. You can simply write a new list widget that shows you everything you would do when you were away (but only once) so you can review what you will miss while you are away.
  • In a similar manner single one off events, deadlines etc… can be built into this with not additional logic.

Using this approach, which is somewhat the reverse, the tiddlers “own their own reoccurrence” as you wanted, but is in many ways far simpler.

  • Store when it was last done then build the lists that determine if it is now due.
  • Allow your tiddlers to be set free and create what ever list you need to meet your needs, at any time now or in the future. Your tiddlers will just follow be there when needed.
1 Like
#6

Hi Tony,

Thanks for your proposal as I was also thinking of how to implement the recurring tasks.

However, my question was about controlling visibility of tasks that have due dates in the future, so tasks not yet done or not yet late. If I have a task that has to be completed (due) by the end of August, it will lie in my scheduled list. But once it’s a middle of the August, I need it to start showing in the Next list so that I know the end date is approaching and I have to do something. In this case it’s two weeks (14 days) before due, but it depends on task complexity so should be definable.

I should have explained it in my post as “due” is differently used from case to case. Sorry for that.

Still, your proposal could probably be applied in my situation somehow, although I have no completed timestamps, of cource. But I like your idea for recurring tasks implementation!

#7

Eric,

Just for my understanding, why the tag{!!title} doesn’t need to go under :filter in order to work?

Thanks!

#8

@rimss,

The approch I suggested is still valid for what you ask, set a future due date using a tag picker. Depending on which list widget you look at it will report items due in a month, a week, a day or even let you chose how many days but the day you do it stamp done date with now.

In fact a tiddler having an empty done date is sufficent to indicate it needs doing, that is it is a todo.

Sorry you weren’t after reoccuring tasks, my post was in many ways trying to be an answer to all posible date questions.