Bug report - Fields in a page do not appear on a task objects

[vitalybe]

What happened?

Per the docs it states:

Tasks inherit all fields from their parent page - so if you have a rating field on your page, you can also access it on your task.

However, it doesn't seem to be true - Tasks don't get any of the fields on the page. When I run this code in a note:

```dataviewjs
console.log(dv.pages('"Obsidian tasks"')[0])
console.log(dv.pages('"Obsidian tasks"').file.tasks[0])
```

The output of the first line is:

Note that the file has fff and tags fields. However, the second line returns the following, without any mentions to the fields of the page:

Here is the full markdown of the page:

---
tags: "#personal"
---

fff:: #umm

# Tasks

- [ ] Tasks

DQL

No response

JS

No response

Dataview Version

0.4.21

Obsidian Version

0.12.19

OS

MacOS

[mnvwvnm]

Hi.

(First of all a previous declaration: I'm not a coder or similar and the language I will use probably isn't the most appropriate...)

Well, how I read the documentation statements:

• tasks are a particular "field", or better, a second level inside the main page level

Dataview tracks information at the markdown page and markdown task levels, where each page/task can have an arbitrary amount of complex (numbers, objects, lists) fields associated with it.

• when in task query, this means that you can filter simultaneously in both levels - e.g., FROM #tag defines the source filtering pages with #tag (tags are always at page level); WHERE contains(text, "job") AND contains(fff, "umm") filter tasks by text (a task implicit field) and fff (a field at page level); ecc.
• if you use this inline js query you can see the "structure" of the fields in your page - $=dv.span(dv.current())

[vcavallo]

I'm not sure which interpretation of the docs is the correct one, but I was also under the impression that individual tasks would "inherit" their parent page's tags and fields.

If that's not the way it's supposed to work, I suggest this as a new feature. Say I have a page for a Project (with a project: XYZ field in the frontmatter) and then have various tasks throughout that page, each with their own contexts. If I'm doing a task query elsewhere and can WHERE project = 'XYZ' that would be extremely powerful and flexible (and to me seems like the expected behavior)

[mnvwvnm]

I'm not sure which interpretation of the docs is the correct one, but I was also under the impression that individual tasks would "inherit" their parent page's tags and fields.

@vcavallo I'm a zero in JS, but I think it's necessary to clarify differences between DQL and JS.

In fact tasks "inherit" their parent page's fields (implicit or others). And your example - WHERE project = "XYZ" - works in intended way. But in my interpretation (and following the @vitalybe post), while in DQL task queries the conditions/filters in "WHERE", for example, work in both levels (page level and tasks level), in JS if you write dv.pages().file.tasks... at this moment, with the expression file.tasks, you are working only in the tasks level, not at page level.

[vcavallo]

interesting... testing this more thoroughly I see that tasks in files that have frontmatter fields are returned in the WHERE, but their fields don't show up in the task output, whereas tasks with the same fields inline do:

[mnvwvnm]

interesting... testing this more thoroughly I see that tasks in files that have frontmatter fields are returned in the WHERE, but their fields don't show up in the task output, whereas tasks with the same fields inline do:

Because the task content (the task text) it's a metadata. Then you see the text (as in normal note in preview/reading mode) that includes the render of the inline fields.

[vcavallo]

So if I'm understanding you, @mnvwvnm, correctly, for a task that appears within a file that itself has fields in frontmatter, there is no way to display those frontmatter fields on the task display, yes?

This is a table output with the full contents of the task objects:

[mnvwvnm]

@vcavallo Yes, at least in DQL. In JS I don't know. You can use a table, but in that case from tasks you can get the text, not a dynamic checkbox.

TABLE file.tasks.text, fieldA, fieldB
...

[zackdn]

I know this thread is really old, but I'd like to bring it up again as this feature would be really great to have. And if it's supposed to work this way already then it would be great to have this bug fixed. @blacksmithgu @mnvwvnm

[AB1908]

What's the use case you have in mind @zackdn?

[Lulullia]

+1 for this bug fix/feature! It's less clutter to have global fields defined at page-level and then use those in queries, overriding as needed. Besides, this already works in DQL so why not JS too?

I use this to define a project's area (eg Writing, Programming etc) like you would with tags. For now I'll figure out a way to add those fields manually in JS or just add them directly to the task...

[AB1908]

This is technically already doable in JS. Simply do page level filtering after dv.pages() before going down to the task level.

dv.pages().filter(t=>t.field == "value").file.tasks

[Lulullia]

@AB1908 thank you, but this won't work for my use case. I need the fields to be in the task itself. What if a task doesn't have the same value as its parent for the same field? It'll get filtered out anyway.

My query works as I want it to right now, it just has a lot of additional lines to transfer parent fields to the task if the task doesn't already have it. If this gets implemented in JS, I can remove those lines, but for now I have found a suitable workaround.

[mnvwvnm]

@Lulullia once in task level you can "build" again the page level. For example, in tasks level we have the link and the path. With it you can target any metadata in page level... for example .where(t => dv.page(t.path).file.name == "title")

[Lulullia]

@mnvwvnm sorry if I haven't expressed myself properly, but I already did this and my query is working as intended now. I don't have any issue right now. Only, having this implemented would allow me to clean up the code by removing those field-adding lines.