Dynamic Variables - documentation anywhere?

I’m exploring some uses for dynamic variables but it’s mostly guesswork at the moment. For instance, I can get <% this month %> to return the start of the current month as [[01-07-2022]], which is useful. But I would also like, for instance, to have it return the name of the month (e.g. [[July]], so I can automatically group certain blocks by month for my billing cycle. Is that possible, or do I have to resort to other kinds of trickery to get this done?

Whatever the answer, it would be really nice to have some more documentation :-).

1 Like

How are you tagging blocks that you would like to group? Or do you want to group them based on their journal page?

The only page I know about dynamic variables is ismschmidtkorth’s unofficial Logseq documentation.

1 Like

The official Logseq Docs also have a page on the Dynamic Variables.
Logseq Docs - Dynamic Variables

I played with dynamic variables a little bit and found this simple query to work using natural language

Query all journal blocks from the first to the 1st of July

{{query (between  <% march 2022 %> <% april 2022 %>)}}

Annoyingly the first day of the next month is included and I cannot find a way to exclude it. <% last day of march %> gives me the yesterday’s date while <% end of march %> gives me the 1st of March.

There is a way to exclude the first of April, but it’s silly.

{{query (and(between <% march 2022 %> <% april 2022%>) (not <% april 2022%>))}}

Took me a while to realize that such a silly and simple solution existed.

The official Logseq Docs also have a page on the Dynamic Variables.

Yes, but it’s just some links from change logs. It’s not even outdated, it’s barely there.

I am experimenting with different options to see what works best. At the moment I am using an attribute template that prefills the date:: and ::month attributes using <% today %> and <% this month %>. I then manually fill in the client:: attribute with a link to the client page and the task:: attribute with the name of the task (based on how we agreed to split up the invoice).
I record each timed activity on the journal page of the day, and (just to be sure) tag it with the client name as well.
This seems to work well enough, except for some nested tasks (where I have sub-tasks under a task): they don’t properly ‘inherit’ the attributes of the parent, from the looks of it. So I was hoping I could either put something in my query like

(<%parent property%> client “Client Name”)

or find another way to have subtasks inherit attributes from their parent.

Yes, it may be a changelog, but I found it very helpful because I was able to use the examples in the “supported variables” to get my own query to work perfectly, and this was the reason I suggested it to you.

1 Like

As far as I know properties are not inherited. While I’d also like to be able to use properties in the way that you’re proposing (or a similar way), I think there is a solution without this being implemented.

If inheriting is important to your workflow, it makes sense to use something that is actually inherited: tags.

Having a seperate tag for each client might be messy, but I think it should be possible to organize this using namespaces like Clients/Clientname. Now tasks will be able to inherit the client’s name without using properties.

Off-topic: XY problem

Off-topic: Your last response explains the problem that you’re trying to tackle much better than your first post, which is solution oriented. So I’m just leaving this here: The XY problem.

1 Like

Thanks for your reply. I haven’t really tried out namespaces yet. Worth a try.

As for the XY problem: I’m experimenting with many different bits and pieces at the moment, and not all are directly related to a single problem I’m trying to solve. Some are just an attempt to better understand the various mechanisms available by which Logseq can help me organise and retrieve relevant information.
I do take your comment to heart, though: next time I will try harder to explain the context of what I am asking.