Bases filter not working

Help
1

What I’m trying to do

I have created a base and filtered it with only two filters:

  • Where “type” is "Meeting
  • attendees.contains(this.file.name)

I can place this base on any Person’s page and the results show me every meeting that had that person listed as an attendee. So for example, if I place this base on a page titled “John Smith”, and I have other notes that are of type “Meeting” and in their Attendees field, any of the values include “John Smith” then that meeting shows up as an output of this query.

This works perfectly nicely. 99% of the time.

I now have two name pages (let’s call them “Mary Smith”, where this exact same base fails to work. When I replace the second filter to say “Attendees.contains” and then add in a hyperlink to “Mary Smith”, the problem gets corrected and the query shows all my meetings with Mary Smith. But if I leave the query as “this.file.name” then the query fails, even though the file’s exact name is “Mary Smith.md”, just like every other person file in Obsidian.

This seems really buggy and I can’t find any inconsistency on my part which might be causing this. Please help!

2

Is there anything special about the name? Any accents/diacritics or emoji or special characters?

Do you potentially have a duplicate named file in a subfolder somewhere? For example “/people/Mary Smith” and “/projects/staff/Mary Smith”

Maybe there is a bug where duplicate names aren’t filtered correctly. But that’s just a wild guess on my part.

3

There are no special characters. I did formerly have the same file name in two different folders and like you, I also thought that might be causing the weird behavior. But since then I have merged the files and made sure there is only one file with that name but the problem remains unresolved.

4

Strange. I wonder if it’s some cache issue. I don’t know off-hand how to clear caches, but I know one can. In the meantime, have you tried just restarting Obsidian?

And if you search the vault for “Mary Smith” are you 100% sure all the instances are gone?

And “Mary Smith” has type = Meeting? I assume yes, because your test worked. I’m just grasping at straws now. If you get rid of the attendees.contains(this.file.name) filter, does the Mary Smith note show up in the full table of type is Meeting notes?

5
  • Tried restarting Obsidian a few times; no luck
  • 100% sure that all instances of “Mary Smith” are gone as a filename. I even deleted the one instance of the file where I’m placing the base, and recreated the file from scratch as a new file, but even that didn’t work.
  • “Mary Smith” has type “Person” (just like all my people do), and the Base is searching for any file with type “Meeting” that has “Mary Smith” listed as an attendee.
  • To answer your question, yes - if I remove the attendees.contains(this.file.name) filter, then all documents that are of type “Meeting” show up correctly.
  • And if I change the attendees.contains(this.file.name) filter to specifically search for attendees that contain “Mary Smith” (as opposed to “this.file.name”) then the filter works correctly as well. Only when I’m using “this.file.name” as the criteria does it go back to showing zero results.
6

1.
Did you double check the attendees lists, that they’re properly linking to the existing, current [[Mary Smith]]? Especially since you’ve merged and changed your Mary notes.

Even if clicking the link in a meeting note’s attendees list takes you to the Mary Smith note, triple check by switching to Source Mode to see that nothing additional is in the link.

If that isn’t what was keeping Mary from her meetings, then a few debugging ideas…

2.
Create a new note “test meeting.md”.
From scratch, add the most basic front matter that should be sufficient to work:

---
type: Meeting
attendees:
  - "[[Mary Smith]]"
---

Does this meeting note show up in the base results in Mary’s note?

3.
How about when you use this filter instead:

attendees.contains(this)

Is Mary still truant?

4.
Create a new base in “Mary Smith.md”.
Add this filter:

file.path == this

Add this property formula:

file.name.toString()

Does the column value show exactly Mary Smith, or is anything amiss with the string?

file name as string
file name as string869×198 10.3 KB

7

@dawni - your suggestions have been extremely helpful - thank you!

  • I realized that while the correctly functioning people links look like this: [[2025/People/John Smith]], the incorrectly functioning people links look like this: [[2025/People/Mary Smith|Mary Smith]].
  • When I manually edit the “Mary Smith” link to remove the “|Mary Smith” at the end, the problem gets corrected.

So now I have some follow-up questions:

  • Why is Obsidian creating the Mary Smith link differently from how it’s creating links to other people?
  • How can I prevent this behavior from happening?
  • How can I quickly correct all the past instances of all people like Mary Smith where the links were created incorrectly?

And the last question, based on your response to me:

  • What does “this” do, as in
    attendees.contains(this)
    Should I be using “this” instead of “this.file.name”?
1 Like
8

It might be a symptom of Obsidian refactoring your links when you merged the duplicates. Depending how you merged. And it might be from a plugin.

If you aren’t aware that pipe syntax is an “alias”. But it’s a bit weird that the filter wasn’t working since the name was still the same as the alias name.

9

A few different things are going on: link path, display alias, and this. This is how I understand it; corrections welcomed…

What does “this” do, as in
attendees.contains(this)
Should I be using “this” instead of “this.file.name”?

Because this is a file:

  • this → “path/to/note”
  • this.file → “path/to/note”
  • this.file.name → “note”.

Thus when your link in attendees has a path[1], these are true:

  • attendees.contains(this)
  • attendees.contains(this.file)

… and this is false:

  • attendees.contains(this.file.name)

which this is this
which this is this1312×834 27.5 KB

Why is Obsidian creating the Mary Smith link differently from how it’s creating links to other people?

Like rigmarole said, perhaps added during refactoring from the merge.

Another possibility is maybe Obsidian always includes a display alias when it, not the user, adds the link path (haven’t tested, just a suspicion).

For example, Obsidian adds a path when your new link format is set to “Absolute path” or “Relative path” (in Settings). It also adds a path—thus maybe the alias too—when linking to one of multiple notes with the same name. You had multiple Mary Smith notes earlier. It’s possible that linking to one Mary Smith without explicitly telling Obsidian which Mary Smith… is what started your whole saga. Prospectively.

And finally, when you merged notes and Obsidian updated the link for you, it retained the presence of a display alias. (This part I’m sure Obsidian does, because some people don’t like the way it chooses the new alias and have posted many-a-thing about it.)

How can I prevent this behavior from happening?

Double check for notes of the same name when linking??

That’s my best guess.

How can I quickly correct all the past instances of all people like Mary Smith where the links were created incorrectly?

Even though they’re not technically “incorrect” and they are usable with the right filters, I know what you mean. And having uniform property values is generally a good idea anyway. So…

To filter for notes where attendees contain a display alias:

attendees.toString().contains("|")

But as Rigmarole mentioned, I’m not sure that that alone caused the problem.

Another possibility is that since we have two filters that give different results, you could pit the filters against each other:

attendees.contains(this) != attendees.contains(this.file.name)

That could turn up notes like Mary Smith. Also might turn up any other irregularities :person_shrugging:.

  1. keeping in mind that when it makes sense to, Bases can resolve links to files ↩︎

1 Like