Getting TasksFile out of Link object?

[janserbus]

I wonder if it is possible to get TaskFile out of Link object in filter by function query?

Ideally i would like to do something to this extend:

filter by function task.file.property("project").toFile()......

where property("project") would return Link or atleast

filter by function task.file.outlinksInProperties.some(l => l.toFile.....)

Is it possible in current version?

[claremacrae]

Hi,

I've read your question several times, and am not confident that I understand it.

1. When you say TaskFile are you talking about this:
   • https://github.com/obsidian-tasks-group/obsidian-tasks/blob/main/src/Scripting/TasksFile.ts
2. When you say Link, are you talking about this:
   • https://github.com/obsidian-tasks-group/obsidian-tasks/blob/main/src/Task/Link.ts
3. What is the real-world scenario of your question - what are you searching for?
4. Could you please supply the text of a Markdown file that I can copy and use for testing.

[claremacrae]

Thank you.

I would really appreciate it if you could answer the 4 points. I asked all 4 for specific reasons.

I am unwell at the moment, and am willing to help as best I can.

[janserbus]

Ok, thank you for your patience.

I want to only filter tasks that are in active project (property status), every project has file representing it, but there are also other notes related to that project via project property.

So in the example i provided, i only want Active task to be present.

example.zip

[claremacrae]

Thank you, I have expanded the files and out them in to a folder in a pre-existing test vault.

So I have changed the Tasks query in Homepage.md to this:

```tasks
not done
preset this_folder
```

I am guessing but I suspect the answers to my questions above are:

1. Yes, presumably...
   • I think its just a typo, not noticing the class name is TasksFile, not TaskFile...
2. Yes, presumably...
3. Trickier - see next message...
4. Files can be expanded from example.zip - thank you, they help.
   • The key extra info is that the Tasks query in Homepage.md is file to look at, and modify the search inside it...

[claremacrae]

OK I am having a look at what you want, now I have test examples - thank you.

[claremacrae]

3. Trickier - see next message...

No, I am too unwell to phrase this clearly.

[claremacrae]

tl;dr

No, it's not possible in a reasonable amount of time, using Tasks 7.21.0

Details

I've spent more than 45 minutes on this today - half an hour of which was after receiving the sample files, for which thanks again.

My conclusion is that the request functionality is not currently possible in Tasks, unless someone is already familiar with the Obsidian API.

What next?

You are welcome to create a Feature Request on the Tasks plugin, if you would like this to be considered for implementation in future.

If I were less unwell I might have been able to make some progress, but I really should focus on getting better.

[claremacrae]

You are welcome to create a Feature Request on the Tasks plugin, if you would like this to be considered for implementation in future.

Actually, no need. I am having a go at implementing it.

[janserbus]

Thank you, I appreciate it.

[claremacrae]

For future programmer reference, someone wrote up some of the ingredients of this in: #93 (comment)

[mdbraber]

@janserbus @claremacrae I've been working on similar thing, so maybe it's helpful to add my ideas here. I've implented a simple asFile() function as an extension to the String object using @mnaoumov excellent Codescript Toolkit taking some suggestions from your joint work here: #3024

The result is this script:

String.prototype.asFile = function() {
	  
	  require("obsidian/app");
      if (typeof app === 'undefined') {
          console.warn('Obsidian app instance not available');
          return null;
      }

	  // Extract the actual filename from the wiki link
	  // Handle both [[FileName]] and [[FileName|Display Text]] formats
	  const linkMatch = this.match(/\[\[([^|\]]+)/);
	  
	  if (!linkMatch) {
		  console.warn('Invalid wiki link format:', link);
		  return null;
	  }
	  
	  const fileName = linkMatch[1].trim();
	  
	  // Find the file in the vault
	  const file = app.metadataCache.getFirstLinkpathDest(fileName, '');
	  
	  if (!file) {
		  console.warn('File not found:', fileName);
		  return null;
	  }
	  
	  // Get the file’s metadata (frontmatter)
	  const metadata = app.metadataCache.getFileCache(file);
	  const frontmatter = metadata?.frontmatter || {};

  
	  return {
		  get properties() {
			return frontmatter;
		  },

		  /**
		  * Check if the file has a specific property in its frontmatter
		  * @param {string} propertyName - The name of the property to check
		  * @returns {boolean} True if the property exists, false otherwise
		  */
		  hasProperty(propertyName) {
			  return propertyName in frontmatter;
		  },
		  
		   /**
			* Get the value of a property from the file's frontmatter
			* @param {string} propertyName - The name of the property to retrieve
			* @returns {any} The property value, or undefined if not found
			*/
		   property(propertyName) {
			   return frontmatter[propertyName];
		   }
	}
};

And I'm using it with my Tasks code like this:

group by function \
	require('./.scripts/asFile.js'); \
	if (task.file.hasProperty('areas')) { return task.file.property('areas')[0].asFile().properties.areas } else { return null }

By any means this is not neat or efficient but it definitely works and I'm hoping to work some more on it. @janserbus the only things I've no exposed are the (frontmatter) properties, but it's trivial to also expose file details.

[mdbraber]

@mnaoumov my feeling is that a require("obsidian/app") is highly inefficient in this code - would you have a suggestion if this could be improved? I'd rather not use something like .asFile(app) but maybe I have to?

[claremacrae]

Hi @mdbraber, well done for getting this working...

I'm really pleased that you figured this out, and also are using mnaoumov's plugin...

I know that this is an experiment, but for anyone considering using it, the Tasks plugin's hasProperty() does some more checks, for example:

obsidian-tasks/src/Scripting/TasksFile.ts

Lines 207 to 223 in f3479d5

	public hasProperty(key: string): boolean {
	const foundKey = this.findKeyInFrontmatter(key);
	if (foundKey === undefined) {
	return false;
	}
	const propertyValue = this.frontmatter[foundKey];
	if (propertyValue === null) {
	return false;
	}
	if (propertyValue === undefined) {
	return false;
	}
	return true;
	}

It would be worth looking at its property() too in the same file...

So just a gentle note to mention to be aware that Tasks behaviours may differ depending on which implementation of hasProperty() is being used...

[mnaoumov]

@mdbraber There are a few concerns there.

1. Polluting String.prototype is against modern development practices.
2. You are calling require("obsidian/app") but not saving it, it's essentially not doing anything. Later on you are using app variable which is a global app variable, which existed regardless of you calling require("obsidian/app") or not.
   So what you can do is

1. Just remove require("obsidian/app") call
2. Or assign const app = require("obsidian/app"), which is future-safe if Obsidian team decides to rename or even completely remove app global variable.

However ideally, the app variable is provided by Tasks infrastructure.

I will see if I can make a proper PR for that.

[claremacrae]

For the avoidance of doubt, I really don't want users to have to write code like this - I want Tasks to provide access to the data that this is working around.

[mdbraber]

I'm posting my current implementation just a reference for anyone would might be interested in creating a multi-level project (or area) organization (my definition of an Area is something that is on-going, mostly interests or job-related efforts, while project are time-finite with a clear state of done)

Consider the following Markdown files:

• Tech.md for the main area of "Tech"
• Obsidian.md for the sub area of "Obsidian"
• Tasks Plugin.md for the sub-sub area of "Tasks Plugin"

Tech.md:

---
categories:
  - "[[Areas]]"
---

# Tech
- [ ] Tech task A

Obsidian.md:

---
categories:
  - "[[Areas]]"
areas:
  - "[[Tech]]"
---

# Obsidian
- [ ] Obsidian task A

Tasks Plugin.md:

---
categories:
  - "[[Areas]]"
areas:
  - "[[Obsidian]]"
---

# Tasks Plugin
- [ ] Tasks Plugin task A
- [ ] Tasks Plugin task B

I'm using this code to add information about areas to all my tasks as a script I load (Tasks.js) on startup with CodeScript Toolkit. See this comment for more info.

import * as Tasks from '../Tasks.js';

export async function invoke(app) {
    window.Tasks = Tasks;
}

export async function cleanup(app) {
    delete window.Tasks;
}

The script to add area information to all tasks:

export function addAreas(task, query) {
	task.areas = [];
	task.allAreas = new Set();
	task.areaLevel = null;

	// Function to find areas in linked files
	const _findAreas = (links) => {
		if (!Array.isArray(links) || links.length === 0) { return null }
		const seen = new Set();
		
		for (const link of links) {
			const file = _asFile(link);
			if (file.hasProperty('areas')) {
				const areas = file.property('areas');
				if (Array.isArray(areas) && areas.length > 0) areas.forEach(area => seen.add(area));
			}
		}

		return seen.size > 0 ? [...seen] : null;
	}

	// Initialize foundAreas
	const foundAreas = [[`[[${task.file.filenameWithoutExtension}]]`]];

	// Build an array of found areas 4 levels deep
	if (task.file.hasProperty('areas')) {
		let current = task.file.property('areas');
		for (let depth = 0; depth < 3 && current; depth++) {
			foundAreas.push(current);
			current = _findAreas(current);
		}
	}

	// Assign areas in reverse order (least specific first)
	for (let i = 0; i < 4; i++) {
		task.areas[i] = foundAreas.at(-(i + 1)) ?? null;
	}

	// Remove overlap between level 1 and level 0
	if (Array.isArray(task.areas[1]) && Array.isArray(task.areas[0])) {
		task.areas[1] = task.areas[1].filter(a => !task.areas[0].includes(a));
	}

	// All areas that a Task could appear in (used for foltering)
	task.allAreas = [...new Set(task.areas.flat().filter(a => a))];

	task.getAreas = (areaLevel) => {
		if(!areaLevel && task.areaLevel === null) {
			//console.log("B");
			const currentArea = `[[${query.file.filenameWithoutExtension}]]`;
			areaLevel = Math.max(0, task.areas.findIndex(a => a?.includes(currentArea)));
		} else if (task.areaLevel) {
			areaLevel = task.areaLevel;
		} else {
			// We should check if areas apply at all
			areaLevel = 0
		}

		if(!task.areas[areaLevel]) return null;

		// Update task.areaLevel to new level
		task.areaLevel = areaLevel + 1; 
		
		// Return current rea
		return addOrder(task.areas[areaLevel]);
	}

	return true;
}

function addOrder(link) {
	// Order for areas
    const orderList = [
        "First",
        "Second",
        "Third",
        "Fourth"
    ];

	// Add string to make sure areas are in order - baed on orderList
    const addOrderString = link => {
        const index = orderList.indexOf(link.replace(/\[\[(?:[^|\]]*\|)?([^\]]+)\]\]/,"$1"));
        return (index !== -1 ? `%%${String(index + 1).padStart(2, "0")}%%` : "") + link;
    };

	// Return string with order
    if (typeof link === "string") {
        return addOrderString(link);
    }

	// Return array with order added to every string in the array
    if (Array.isArray(link)) {
        return link.map(addOrderString);
    }

    return link;
}

function _asFile(linkString) {
	  
      if (typeof app === 'undefined') {
          console.warn('Obsidian app instance not available');
          return null;
      }

	  // Extract the actual filename from the wiki link
	  // Handle both [[FileName]] and [[FileName|Display Text]] formats
	  const linkMatch = linkString.match(/\[\[([^|\]]+)/);
	  
	  if (!linkMatch) {
		  console.warn('Invalid wiki link format:', link);
		  return null;
	  }
	  
	  const fileName = linkMatch[1].trim();
	  
	  // Find the file in the vault
	  const file = app.metadataCache.getFirstLinkpathDest(fileName, '');
	  
	  if (!file) {
		  console.warn('File not found:', fileName);
		  return null;
	  }
	  
	  // Get the file’s metadata (frontmatter)
	  const metadata = app.metadataCache.getFileCache(file);
	  const frontmatter = metadata?.frontmatter || {};

  
	  return {
		  get properties() {
			return frontmatter;
		  },

		  /**
		  * Check if the file has a specific property in its frontmatter
		  * @param {string} propertyName - The name of the property to check
		  * @returns {boolean} True if the property exists, false otherwise
		  */
		  hasProperty(propertyName) {
			  return propertyName in frontmatter;
		  },
		  
		   /**
			* Get the value of a property from the file's frontmatter
			* @param {string} propertyName - The name of the property to retrieve
			* @returns {any} The property value, or undefined if not found
			*/
		   property(propertyName) {
			   return frontmatter[propertyName];
		   }
	}
};

I'm adding all the areas information to my tasks by running a filter by function in a global query, so all Tasks always have this information. ⚠️ This should be considered a hack using the filter by function ⚠️ But it works great! 😎

filter by function Tasks.addAreas(task, query)

I can write a query like this in a file that is an Area to filter all the descendants and grouping is automatically taking care of, no matter how many sublevels (I've just limited to 5 to be practical). This means I can create a preset in the highest area level (e.g. Tech) or a sublevel - and not have to worry about the number of group by clauses I need to use (so I can do with the same preset always)

filter by function task.allAreas.includes("[[" + query.file.filenameWithoutExtension + "]]")
group by function task.getAreas()
group by function task.getAreas()
group by function task.getAreas()
group by function task.getAreas()
group by function task.getAreas()

[claremacrae]

I have made a test build of a possible implementation of this, to allow experimentation and feedback.

See:

• spike: Experiment with chaining links together #3639

See that link for how to instal it, and how to use it.

[claremacrae]

Ah, Tasks is only listening out for Properties changes in:

• File containing the query
• File containing the task

Up until now, it has had no reason to believe that changes in any other file should require tasks search results to be redrawn.
Could that be the problem?

[claremacrae]

Thank you very much for testing it out, @janserbus...

[janserbus]

Up until now, it has had no reason to believe that changes in any other file should require tasks search results to be redrawn.
Could that be the problem?

Yes, that explains it. Thank you

[claremacrae]

I found that in Obsidian 1.10.0, I found that when I edit a property in a note, Bases also only immediately updates that property's row.
Any rows with properties calculated from an edited property aren't updated.

Here is an example 1.10.0 note with a base in, to demonstrate. If you edit status value, in the column called "note status", only that row is updated, and not the other notes "in" the same project,

Homepage - Bases.md

[claremacrae]

For Tasks, the workaround is to install this plugin:
https://github.com/mnaoumov/obsidian-refresh-any-view

It puts a reload button at the top of each Markdown note, forcing views to refresh - and this updates all Tasks code blocks on the page.

[claremacrae]

My own feedback on the experiment in #3639:

Because @mnaoumov said not to pollute string, I ended up with a new method propertyAsLink() - I really don't like it, I would much rather have this:

group by function 'Level 4 link: ' + \
    task.file.\
        property('link_to_file').asFile().\
        property('link_to_file').asFile().\
        property('link_to_file').asFile().\
        property('link_to_file').markdown

than this:

group by function 'Level 4 link: ' + \
    task.file.\
        propertyAsLink('link_to_file').asFile().\
        propertyAsLink('link_to_file').asFile().\
        propertyAsLink('link_to_file').asFile().\
        propertyAsLink('link_to_file').markdown

But this is not important enough to be a breaking change - so I still want plain property('link_to_file') to return a string, or something that behaves identically to sting.

[mdbraber]

I'm assuming the first would mean to automatically convert properties to their own type? So property('[[Test]]') would yield a Link object? That object could operate like a String or an Array, but also include their own methods. I'm thinking of Bases formulas as a reference here.

I agree the first option would have preference, but I'm guessing you're referring to typeof would always return object rather than string for custom classes (and therefore be a breaking change)?

[claremacrae]

I'm assuming the first would mean to automatically convert properties to their own type? So property('[[Test]]') would yield a Link object? That object could operate like a String or an Array, but also include their own methods.

Erm, that sort of thing.

But the main point is that I don't know the specifics of how it could be implemented. I tried getting Claude to produce an implementation that would not be a breaking change - but it kept on coming up with things that required me to update the existing automated tests to keep things passing, so fairly likely to be breaking changes!

I'm thinking of Bases formulas as a reference here.

Yeah, the expectation that Tasks will be able to do what 3 full-time developers have been working on for many, many months is a bit of a discouragement for me right now.

I agree the first option would have preference, but I'm guessing you're referring to typeof would always return object rather than string for custom classes (and therefore be a breaking change)?

Yes that. And/or that Tasks has to re-implement all the string methods to retain backwards compatibility.

[mnaoumov]

As previous implementation returned string and users already have logic that depends on the fact there are string, then changing return type to something else is a breaking change.

I think the most elegant way to fix it is

```tasks
---
apiVersion: 2
---
group by function 'Level 4 link: ' + \
    task.file.\
        property('link_to_file').asFile().\
        property('link_to_file').asFile().\
        property('link_to_file').asFile().\
        property('link_to_file').markdown
```

Assuming that by default the version was 1.

This way you can slowly evolve people to first explicitly switch to

```tasks
---
apiVersion: 1
---
```

And possibly eventually deprecate version 1 and force everyone to migrate to the newer API version.

[claremacrae]

As previous implementation returned string and users already have logic that depends on the fact there are string, then changing return type to something else is a breaking change.

Great, thank you for confirming that.

And thank you for the suggestion, too.

[claremacrae]

Since the Obsidian 1.10.0 API is now released and their Bases API is now public, I’ll pause on this for a little while, until I have time for a more thorough think about what to do next.