Expose query.file.property similarly to task.file.property

[jbusecke]

⚠️ Please check that this feature request hasn't been suggested before.

• [X] I searched previous Ideas in Discussions didn't find any similar feature requests.
• [X] I searched previous Issues didn't find any similar feature requests.
• [X] I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
• [X] I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

First of all a huge thanks for maintaining this awesome plugin!

I believe my request is an extension of https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2480 mostly. I would like to be able to access the file properties of the query file exactly like one is able to access them on for tasks. I think this would be particularly useful for workflows involving templates.

✔️ Solution

This already works I can make a template for an index file where I add a task block that will capture tasks whos file property matches a certain value similar to this:

```tasks
filter by function task.file.property('status') === 'in progress'

But I am thinking of another use case where I want to define a value in the query notes frontmatter and then match tasks based on that value (without having to modify the templates task block).

An example: I am creating a 'cooking' index note with a property `matching_tag`:`cooking`. 

Ideally the note has a task block like this:

filter by function task.tags.contain(query.file.property('matching_tag'))

Which would then give me all the tasks in my vault that have the tag `#cooking`. 

I believe this would be very handy to organize notes that pull together tasks from many different (e.g. daily planner) notes, particularly if you have several task blocks that add additonal filters (e.g. different task blocks for overdue, due soon, scheduled that all show only tasks with the #cooking tag). 

Exposing `query.file.property` in the same way as `task.file.property` is also fairly general and might help other folks. I am unfortunately not very familiar with the internals but was hoping that this might not be too complex, since it might be similar to the recent addition to expose task.file.property? 

### ❓ Alternatives

The only way I have found to make this work currently is to enter the value manually like this:

filter by function task.tags.contain("#manually_added_tag")

which works, but is much more prone to typos and needs additional user intervention.

### 📝 Additional Context

It seems that what I describe was already part of the testing [here](https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2480#issuecomment-2223266515)? Maybe I missed an issue that is tracking this already?

[claremacrae]

Hi thanks for the suggestion. There seems to be a problem with the formatting of text which makes it hard to read.

Could you edit the description and fix it please?

[jbusecke]

Ah sorry about that, just fixed it. Thanks for the ping.

[jbusecke]

This feature would open up a bunch of opportunities to interact with other plugins too. Just as an example, one could define a button using meta-bind that modifies a property (to e.g. #personal #work) and could then have the task block update dynamically and show only work/personal tasks. One could build an entire task dashboard this way I guess 😁

[claremacrae]

I had the code for this when working on #2480 and it was buggy.

IIRC The biggest problem was that the query was not updated when I edited the frontmatter in the file containing the query, so I had to close and re-open the query file every time I edited its frontmatter.

So it was clearly not releasable, and I chose to release access to task.file.property as a first step, and document the limitation in https://publish.obsidian.md/tasks/Getting+Started/Obsidian+Properties#Limitations

I will edit that docs to reference this issue.

[claremacrae]

I will edit that docs to reference this issue.

Done:

[jbusecke]

Thanks for the explanation. Curious to see if there might be upstream improvements that fix this eventually.

[claremacrae]

Thanks for the explanation. Curious to see if there might be upstream improvements that fix this eventually.

No, it is code that needs to be written in Tasks. It is just competing with a lot of other requests, and finite development time.

[jbusecke]

Ah got it. Either way, just wanted to say again how much I appreciate all the work on this great plugin!