So, I have some queries in my config.edn to render them in every journal page. And that’s basically the problem I bumped into, in the sense that they’re rendering correctly ONLY for today.
So, if I want to go back to say 5 days ago, I want them also to render in that page, and so on. I don’t want to be constrained to have my queries only on the day in course.
As the buffer is 7 days, I’d like the inputs to be calculated in regards to the journal date (maybe getting journal page title as input? idk).
I’m experienced in Python, but Clojure escapes my programming skills. Could anyone help me out with this one? This is a wonderful community and software, keep it up!
P.S. By any chance can I sort in reverse and group by page at the same time? It would be helpful if the first results in overdue were from the oldest page, not from the earliest.
They do not in fact work like that.
They only show on today’s journal page.
So what you would actually want to do is create a template with the desired query and then have the config.edn add that to each (new) journal page.
Something I’ve written about on my blog:
We shall all long for the day this becomes possible
It’s either you sort, or you group by page.
Can change to table output to show block and page and also have sorting, if that is useful.
I find that personally to work only in some instances.
Hey, just saw you’re doing an awesome job in the forum, read through this thread: https://discuss.logseq.com/t/queries-for-task-management and started to get a grasp of query syntax. Thanks for that! Also, didn’t think of the proposed solution of including the queries as template, thanks! (btw, after carefully thinking about it, I’m actually going down another route and having a general task page, I worry that rendering those queries for every journal page would impact performance, what do you think about this and which is your preferred workflow?)
I’ll keep your blog in my radar, you’re a full knowledge base by itself!
P.S. I want to use the repeaters in some of my queries (TODAY’s and NEXT), but using :block/repeated? true falls a bit short, since I would like to actually show the repeated task only when the repetition is scheduled.
I’ve been reading the mentioned thread and took a look here, but couldn’t find how to do arithmetics on repeated date.
I currently don’t look at my journal pages itself at all. So I don’t have queries on them. I do near every entry in the journal through my start page.
I do some interesting queries on my reflection page, for planning my tasks.
I also have a general tasks page which has some queries, but is mainly to hold all my repeating tasks.
anything that is past due date, that is also not on my week plan
unplanned
anything without a scheduled date that is a task on a journal page. (I don’t want to show all my project/game tasks)
planned
anything scheduled, outside of repeating tasks
shopping
anything labeled shopping, but not clothes
shopping clothes
anything labeled shopping and clothes
daily tasks
weekly tasks
monthly tasks
yearly tasks
I kind of abuse the priority system to give priority X to daily, priority Y to weekly and priority Z to monthly tasks. (they are also not strictly on that rotation. For example daily is anything between every day and every 6 days etc)
This way I can apply some extra filtering in my queries through :block/priority.
I barely use this page though. I mostly use my start and my contents pages in daily use.
They have queries to get relevant information for today.
I have review moments on a weekly and 6 week basis to look at other tasks.
With the caveat that I don’t have a big task list anyway. So yeah.
As for performance, queries are rendered on a per page basis. So it doesn’t matter how many pages have queries, it matters how many queries a page has. And also how the queries themselves perform. My contents page is a huge page of queries, but I have no performance issues with it as the queries themselves are fast. Also they have lazy loading, so not everything is loaded all at once.
lol thanks
I wish I could do more in terms of sharing my knowledge in a more organized manner through my blog. But being exhausted all the time has not been helping.
Exactly like that!
Input like :today gives an integer of yyyymmdd (eg. 20240721)
The scheduled attribute also is an integer of yyyymmdd. Just as journal-day attribute is.
So to give quite an extensive example, I have a query to find tasks that are scheduled for today, but that I haven’t put down on today’s plan.
#+BEGIN_QUERY
{:title [:b.h.subtle "☑️ Gemist op de planning"]
:inputs [:today]
:query [:find ?has-child (pull ?b [*])
:in $ ?dag
:where
;tasks planned for today
[?b :block/marker "TODO"]
[?b :block/scheduled ?dag]
;no subtasks. There's a special reason I have this and I keep forgetting why :D
(not
[?b :block/parent ?x]
[?x :block/marker "TODO"]
[?x :block/scheduled ?dag]
)
;exclude tasks that are planned in
;either today or later
;my weekplanning page references journals,
;that's how I can filter that easily
(not
[?w :block/name "weekplanning"]
[?plan :block/page ?w]
[?plan :block/refs ?b]
[?plan :block/path-refs ?j]
[?j :block/journal-day ?jd]
[(>= ?jd ?dag)]
)
;exclude any daily tasks, like I said abusing the priority system here.
;normally it only has A B & C as options
(not [?b :block/priority "X"])
;some code for showing blocks with children as collapsed in the results.
(or-join [?b ?has-child]
(and
[?child :block/parent ?b]
[(not false) ?has-child]
)
(and
(not [?child :block/parent ?b])
[(not true) ?has-child]
)
)
]
:breadcrumb-show? false
:result-transform :sort-tasks-collapsed
}
#+END_QUERY