Dynamic file properties and formulas in each note (YAML)

Feature requests
, ,
1

Use case or problem

Bases introduced powerful formula properties and dynamic file properties like file.mtime and file.size.

Unfortunately, both can only be used and viewed within a base.

Proposed solution

Add support for the two new property types—file properties and formula properties—to frontmatter in-note.

For example, if we input the following values in note YAML:

---
reading_speed: 250
words: 1000
time to read: "words / reading_speed"
modified time: "file.mtime" 
file size: "file.size"
---

The output would be:

---
reading_speed: 250
words: 1000
time to read: "4" # Calculated dynamically based on values of above properties
modified time: "2025-08-01 03:32" # Updated dynamically
file.size: "1 KB" # Updated dynamically
---

A view to create or edit a formula property could be brought up when opening the context menu for the formula property type.

In particular, the dynamic modified time property would be amazing and is in high demand:

In my experience, the community plugin solutions that accomplish this are unreliable.

Current workaround (optional)

Related feature requests (optional)

15 Likes
2

This can’t be. Notion can never have an offline mode and Obsidian can never have a formula property. It’s just laws of physics. Jokes aside, I hope this is added. It’s overdue since Pythagoras was born.

3
4

The functionality they’ve added is respectable, but calling it “offline mode” is playing with users’ feelings. Still, both apps are moving toward their respective epiphanies. So, I digress!

5

Man, they really ought to add this feature. It is so within the app’s range, and will also be universally useful to practically everyone!

2 Likes
6

As a matter of example.

Imagine you have a base with games, and each game has Steam ID property. Instead of having to manually fill in other properties with this very Steam ID that would form links to for example launch the game, a simple formula could take that property and add it to the link, dynamically updating it.

Source: https://www.reddit.com/r/ObsidianMD/comments/1oxpk1j/are_there_other_useful_universal_link_for_apps/

7

The way I see this being implemented is with formulas being made in the settings, and either

  1. any note that has the property(s) the formula requires this formula will be shown in;
  2. or you have to specifically add the formula like you would with a property, and if not already present it would add the required properties.

To reuse @peeragetalkers example from their original post, you would define the following in settings:

time to read: "words / reading_speed"
modified time: "file.mtime"
file.size: "file.size"

Whenever a note has both the properties words and reading_speed, the formula time to read would be shown too (as described in option 1 above; syntax illustrative, using a predefined property that gets rendered in a different way):

---
reading_speed: 250
words: 1000
showformulas:
    - "time to read"
---

In the case for the formulas modified time and file size, you would have to manually add those formulas as if you would add a property (option 2 above), then it would add them to the showformulas list:

---
showformulas:
    - "modified time"
    - "file size"
---

The only problem with this approach would be the abstraction (if that is the correct word) from the formula name in the properties, and what the formula does. On the other hand, this ensures all notes with this formula shown are always gonna have the exact same formula, unlike if you were to write the formula as you would properties.

Whenever you are exporting a note with visible formulas, they would be “collapsed” to their outcome, even if exported to markdown files, to keep the data intact:

---
reading_speed: 250
words: 1000
time to read: 4
modified time: "2025-11-22 16:50"
file size: "2 KB"
---

I would assume any and all functions available to Bases formulas would be available here too, although html() could be a little hard to make work correctly (but would be really cool if it were to be implemented too).

Tell me what you think of this different approach, potential pros/cons you can think of?

Additional idea

It would be cool if note formulas had access to some more stuff, for example headers and their hierarchy for automatic table of contents at the top of the page.

8

I don’t understand why the formula property would reference formula definitions defined in the settings, rather than simply containing the definition of the formula directly.

I could see it being nice to have commonly used formulas easier to access (e.g. “file size”), but it feels like you could simply address that with a note template that pre-fills the necessary formula content. Introducing a settings page for managing formulas, then introducing new reserved property names like “showformulas” feels like more trouble than it’s worth (in my opinion).

9

I came up with a potential implementation, not how it has to be implemented.

Storing the formula in the property itself does make sense too, but the ease of reusing may get a little less easy (you’re saying to use a template, that’s still a few more steps than just adding a predefined property).

10

I would use file & formula properties (or something like them) in a heartbeat.

However, practically no one uses properties, bases, or complex formulas. Nowadays we rarely guide users to properties & links; instead they’re advised to use folders & tags. If you analyze the folks here on discourse and on discord there’s only dozens, maybe a few hundred folks who actively talk about these “advanced” features.

Sadly, I too digress… bring it on!

1 Like
11

Same. I hoped to have file properties since I started using Obsidian.

1 Like
12

Desperately need this.

I am using Obsidian to plan out a story. I create notes for each scene of the story and want to display the scenes in a base in the correct order by including the following properties:

  • previous_scene: A link to the note of the scene that happens after the current scene
  • next_scene: A link to the note of the scene that happens after the current scene
  • index: The index of the scene. This will be used to correctly order the scenes in a base

Doing it like this (like a linked list) allows me to easily specify the order and correctly change it when I add scenes between existing ones. If I wouldn’t do it like this, I would have to update the index for a lot of notes each time I add a new scene in between.

To achieve the correct order in a base, the indexproperty would need to change dynamically depending on what the index of the previous scene is. More specifically: current-scene.index= previous-scene.index + 1

The formula to get the incremented index would be

file(note.previous_scene).properties.index + 1

All that’s missing is the ability to save the result of this formula into the index property so that the next scene note can use this index to calculate its own index.

If anyone has any idea on how else I could achieve this, please share.

1 Like
13

I do hope this gets implemented. Having built the formulas for bases - I was surprised to learn that the properties created via formula don’t actually get applied back to the files themselves. I expected once I created the formula to go check out the files and see the new formula-driven properties. Alas this was not the case.

I set about trying to create a plug-in to do exactly this… but wound up sort of zigging rather than zagging.

Long story short - I sort of did it, but also it doesn’t do what you’ve asked for. It does allow you to create automatically-updating properties based on rules, but the rules are based on the content of the note itself, rather than other properties. Also - the rules (formulas, in your case) aren’t applied at the note-level, they are defined at the vault level, and then applied to the note by including the relevant key.

The plugin is currently awaiting review & approval. If you’re interested in this feature request, I assume you might be interested in it. Here’s a demo video I made, if interested.

14

I’ll save you from having to read my thing below - sadly it wouldn’t address your use case.