Name: Conditional Properties – Obsidian Plugin · Obsidian Stats
Rating: 49 (25 reviews)
Author: Diego Eis

by Diego Eis

Score: 49/100

Install Code

Description

Category: Productivity Tools

#front-matter #metadata #rules #bulk-editing

The Conditional Properties plugin automates frontmatter management using IF/THEN rules that eliminate repetitive manual updates. Define conditions based on property values or note titles, then apply actions like adding tags, removing values, overwriting properties, or deleting them entirely. You can also modify note titles with prefixes, suffixes or complete overwrites using dynamic placeholders for dates and filenames. Rules support six operators including exact matches, contains checks, and existence tests. Multiple actions can be combined in a single rule for complex workflows. Execute rules on demand across your entire vault or just the current file or schedule automatic scans at intervals targeting the latest created notes, latest modified notes or everything.

Reviews

Diego Eis
Reviewed on Feb 10th, 2026
No review text provided.
Ganessh Kumar R P
Reviewed on Jan 11th, 2026
No review text provided.

Stats

stars

3,192

downloads

forks

171

days

total PRs

open PRs

closed PRs

merged PRs

total issues

open issues

closed issues

commits

Latest Version

0.20.4

9 days ago

Changelog

0.20.4 - 2026-06-18

Fixes

No more scroll-to-top or lag on any settings interaction. Every remaining this.display() call inside the settings UI has been replaced by a localized DOM mutation:
- Changing the Scan scope no longer rebuilds the page — the "Notes to scan" row is now created once and toggled via an is-hidden class.
- Add rule appends the new rule's wrap right after the Add button instead of re-rendering all rules.
- Changing a condition's Property / First level heading type, or its operator, rebuilds only that single condition row in place.
- Changing an action's Property / First heading type, or its action (add / overwrite / delete / rename / …), rebuilds only that single action row in place.
The only display() left in the settings UI is on Import settings, where rebuilding the whole tab is the right thing to do (every field potentially changed).

Internal

Eliminated dead code (_updateValueInputState, never called).
Removed the unused ruleIdx parameter from _renderThenAction and call sites.
Translated lingering Portuguese comments to English (or removed them when they only restated the code).
Replaced fragile class-based DOM lookups (.extra-setting-button, .conditional-match, .setting-item-name) with explicit references on ruleCtx:
- ruleCtx.matchWrapEl — the Match dropdown element, null when absent.
- ruleCtx.removeBtnByCondition — WeakMap<Setting, HTMLElement> mapping each condition's Setting instance to its ✕ button element.
- ruleCtx.actionEntries — array of { el, setting } per action row, so reindexing and rebuilds use the Setting instance directly instead of querying the DOM by class.
Added _rebuildCondition(ruleCtx, cond) and _rebuildAction(ruleCtx, action) to encapsulate the "this row's shape changed, redraw just this row" path that used to be a full display().
Added an is-hidden utility class in styles.css so visibility toggles stay in CSS instead of being scattered as inline style.display = '…' assignments.

0.20.3 - 2026-06-18

Fixes

The rule-level Remove button no longer scrolls or lags either. The same display() call that 0.20.1 and 0.20.2 eliminated for rows was still firing when an entire rule was removed. The rule's wrap element is now detached in place; the other rules stay exactly where they were on screen.

Internal

The Remove handler unsubscribes the rule's onScanStateChange listener and prunes it from _scanStateUnsubscribers before detaching the DOM, so removed rules don't leave dangling subscribers behind.
Both Run this rule and Remove resolve the rule's current index via Array#indexOf(rule) at click time instead of trusting the idx captured at render time. With re-renders gone, the closure-captured index would go stale after any other rule was removed and we'd run / delete the wrong one.

0.20.2 - 2026-06-18

Fixes

Removing a condition or action no longer scrolls or lags. Same root cause as 0.20.1 — the per-row Remove (✕) button still called display(), which destroyed and rebuilt the entire settings tab. Now the removed row's DOM is detached in place; the remaining rows are reindexed (Condition 1, Condition 2, …) via the Setting instance, and when a rule drops back to a single condition the Match (any/all) dropdown and the last Remove ✕ are stripped without re-rendering.

Internal

Introduced a per-rule ruleCtx object ({ wrap, ifHeader, rule, conditionSettings, actionWraps }) shared between _renderRule, _renderCondition, _renderThenAction, _addConditionRemoveButton, and _ensureMatchDropdown. Remove handlers mutate this context instead of falling back to a full re-render.
Condition rows are tracked as Setting instances so setName() is enough to reindex; action wraps are tracked as their root elements and reindexed via a scoped querySelector for .setting-item-name.

0.20.1 - 2026-06-18

Fixes

"+ Add condition" and "+ Add action" no longer scroll the settings tab to the top. Previously each click re-rendered the entire settings UI via display(), which destroyed and recreated every rule and reset the scroll position — making it impossible to keep your eyes on the rule you were editing. The new condition/action is now appended in place, right above its "Add" button.
New conditions/actions appear instantly. The full re-render was also responsible for the lag — every existing rule, condition and action was being rebuilt on each click. Only the new row is created now.
The Match (any/all) dropdown is materialized on the fly the first time a rule gets a second condition, and the per-condition Remove button is wired into the previously-single condition at the same moment — no element is destroyed and recreated.

Internal

_renderCondition() and _renderThenAction() now return the elements they create (the Setting and the wrap div), so callers can insert them at a precise position without resorting to lastElementChild or DOM scraping.
New helpers _ensureMatchDropdown(ifHeader, rule) and _addConditionRemoveButton(settingLine, rule, cond) extract the dynamic-mutation logic. The Remove handler looks up the condition's current index via Array#indexOf instead of capturing it in a closure, so removals stay correct after subsequent additions.
Remove handler for actions does the same indexOf lookup, fixing a latent off-by-one when an action is deleted after another was appended.
All DOM lookups remain scoped to elements the plugin owns (settingEl.querySelector(...), ifHeader.querySelector(...)); no global document.querySelector was introduced. No innerHTML, var, or unregistered listeners were added — Obsidian's createEl / createDiv and the Setting / DropdownComponent / ButtonComponent APIs are used throughout, in line with the project's plugin guidelines.

0.20.0 - 2026-05-19

New Features

Frontmatter property placeholders in THEN values. Any {propertyName} reference inside a THEN action's value (property add/overwrite/remove, title prefix/suffix/overwrite) is now expanded to the live value of that frontmatter property on the note being processed. Example: an action Property excerpt = Add value {g_excerpt} copies the contents of g_excerpt into excerpt.
Missing properties expand to an empty string — no error, no literal {name} left behind.
Array values are joined with , so a multi-valued source like tags produces a readable string.
The reserved placeholders {date}, {date:FORMAT}, and {filename} keep their existing meaning; they're resolved first and never collide with property lookups.

Internal

_formatText(text, file) now takes an optional third argument fm (the in-progress frontmatter snapshot). All four call sites inside applyRulesToFrontmatter pass newFm, so a later action in the same rule sees the writes performed by earlier actions. When fm is omitted, the helper falls back to metadataCache.getFileCache(file).frontmatter.
Placeholder resolution is now a two-pass replace: pass 1 handles {date}/{filename}; pass 2 treats any other {name} token as a frontmatter lookup. The pass-2 regex excludes : and whitespace, so a malformed {date:FORMAT} survivor would not be mistaken for a property name.

Why

Users storing canonical content in one property (g_excerpt, g_title, summary, ...) and needing to project it onto another (excerpt, description, ...) previously had to copy by hand. This closes that gap without inventing a new action type — the existing add/overwrite/title actions just gained a richer expansion grammar.

See all version on GitHub

README file from

Github

Conditional Properties for Obsidian

Automate your frontmatter with smart IF/THEN rules. Set properties, modify titles, and keep your vault organized—automatically.

Plugin Interface

Why Use This Plugin?

Stop manually updating properties across hundreds of notes. Define rules once, run everywhere. Perfect for:

🏷️ Auto-tagging notes based on content
📊 Maintaining consistent metadata
🔄 Bulk property updates
⏰ Scheduled maintenance
🎯 Targeted scope (latest created/modified notes)

Core Features

🎯 Flexible Conditions

Multiple conditions per rule (new in v0.17.0): combine conditions with Match any (OR) or Match all (AND) — inspired by Zotero's "match any/all of the following" UI.
6 operators: exactly, contains, notContains, exists, notExists, isEmpty
Property-based: Check any frontmatter property
Title-based: Use note titles (H1 or inline) as conditions

⚡ Powerful Actions

ADD: Add values without duplicating
REMOVE: Remove specific values
OVERWRITE: Replace entire property
DELETE PROPERTY: Remove property completely
CHANGE TITLE: Add prefix/suffix or overwrite with dynamic dates, filenames, or other property values
Placeholders in action values (new in v0.20.0): reference any frontmatter property inline as {propertyName}, alongside the existing {date}, {date:FORMAT}, and {filename} placeholders. Works in property values and in title text.
Typed property awareness (new in v0.19.0): when the target property is registered as checkbox, date, or datetime, values are written with the right YAML type instead of as plain strings — so whatsapp: true lands as a real boolean (renders as a checked checkbox), and created_at: 08-08-2025 is parsed and stored as 2025-08-08 (renders in the Obsidian date widget).

🎛️ Smart Execution

Run on demand: Entire vault or current file only
Stop button (new in v0.18.0): cancel a running scan; the current file finishes cleanly and remaining files are skipped
Scheduled scans: Set intervals (min 5 minutes)
Scoped scanning: Latest created, latest modified, or entire vault
Configurable count: Process 1-1000 notes at once

🛡️ Safe & Private

Only modifies frontmatter (body content preserved)
All processing happens locally
No data leaves your device

Quick Examples

Auto-tag meetings:

IF property: type = "meeting"
THEN ADD tags: work, important

Archive old projects:

IF property: status = "archived"
THEN REMOVE tags: active, wip

Date-stamp completed tasks:

IF property: status = "done"
THEN Change Title: Add suffix " - {date:DD/MM/YYYY}"

Standardize meeting note titles:

IF title contains: "Meeting"
THEN Change Title: Overwrite to "{date:YYYY-MM-DD} - {filename}"

Result: 2026-01-08 - team-sync

Clean up deprecated data:

IF property: tags = "old-project"
THEN DELETE PROPERTY: legacy_data

Title-based tagging:

IF title contains: "Meeting"
THEN ADD tags: meeting, important

Typed Properties (Checkbox / Date / Datetime)

Some Obsidian property types have native widgets (the checkmark for checkbox, the calendar for date, the calendar+clock for datetime). For the widget to render correctly, the YAML must store the value with the right type — boolean for checkbox, ISO date for date/datetime. Strings won't trigger the widgets, even if the property is registered with the right type.

Since v0.19.0, the plugin detects when the target property is one of these types and converts the rule's value automatically. You can keep writing rules with plain text and the plugin handles the rest.

Checkbox

IF property: status = "done"
THEN OVERWRITE property: completed = "true"

Result on disk: completed: true (boolean). Obsidian renders a checked checkbox.

Rules:

"true" (any casing) → true
Anything else ("false", empty, "sim", etc.) → false

Date / Datetime

IF property: status = "done"
THEN OVERWRITE property: created_at = "08-08-2025"

Result on disk: created_at: 2025-08-08 (ISO date). Obsidian renders the date widget.

How the date parsing works:

If your input is already in YYYY-MM-DD, it's stored as-is.
Otherwise, the plugin tries to parse it using the Daily Notes core plugin's date format (if enabled), then the Templates core plugin's date format (if enabled), then a few common civilian formats (DD-MM-YYYY, DD/MM/YYYY, YYYY/MM/DD).
The first format that parses successfully wins — the value is converted to YYYY-MM-DD before being written to the YAML.
If nothing parses (you typed garbage), the input is written as-is and the property won't render in the date widget. The plugin doesn't validate format beyond that — garbage in, garbage out.

Datetime properties (YYYY-MM-DDTHH:mm:ss) are not parsed and are written exactly as typed. The Obsidian datetime widget will render them when the input is already in the expected ISO datetime form.

Notes

This applies to both ADD value and OVERWRITE all values with actions on typed properties. For these types ADD behaves as OVERWRITE because the underlying types are scalar (you can't have a checkbox holding [true, false]).
Properties without a registered type (or registered as text, number, multitext, tags, etc.) keep the original string-based behavior. Nothing changes for those.

Typed properties also work on the IF side (since v0.19.1)

The same type-aware coercion now happens when matching conditions, not just when writing actions. You can author IF rules using whatever date format you prefer and the plugin will normalize before comparing against the ISO value stored in YAML.

IF property: created_at exactly "08-08-2025"
THEN ...

matches a note whose YAML stores created_at: 2025-08-08. The same applies to contains and notContains. For checkbox properties, IF property: done exactly "true" matches a note with done: true (boolean) regardless of how the user typed true (case-insensitive).

Multiple Conditions Per Rule

Combine conditions inside a single rule using Match any / Match all of the following (inspired by Zotero).

AND example — match all of the following:

Match all of the following:
  - property: status = "done"
  - property: priority = "high"
THEN ADD tags: urgent-completed

OR example — match any of the following:

Match any of the following:
  - property: status = "archived"
  - property: deleted = "true"
THEN REMOVE tags: active

Click + Add condition below the IF block to add more conditions, and the dropdown to switch between any and all. Existing rules from previous plugin versions are auto-migrated and keep their behavior unchanged.

Multiple Actions Per Rule

Combine actions to automate complex workflows:

IF property: project_status = "completed"
THEN:
  - SET status [OVERWRITE]: done
  - ADD tags: archived
  - REMOVE tags: active, wip
  - ADD priority: low

Scan Scopes

Choose what to scan:

Latest Created: Process newest notes (default: 15)
Latest Modified: Process recently edited notes (default: 15)
Entire Vault: Process all notes

Perfect for running rules only on active notes instead of your entire vault.

Operators Reference

Operator	Description	Example
`exactly`	Exact match	`type = "meeting"`
`contains`	Substring match	`name contains "Diego"`
`notContains`	Does not contain	`tags notContains "draft"`
`exists`	Property present	`status exists`
`notExists`	Property absent	`reviewed notExists`
`isEmpty`	Empty value	`tags isEmpty`

Title Actions

Modify note titles dynamically:

Prefix: [ARCHIVED] Original Title
Suffix: Original Title - {date}
Overwrite: Replace entire title with custom text

Placeholders

Placeholders work inside any THEN action value — property Add value / Overwrite all values with, and title Prefix / Suffix / Overwrite. They're expanded at the moment the rule runs, against the file being processed.

Placeholder	Result
`{date}`	File creation date in the default format (`YYYY-MM-DD`). Example: `2026-01-08`.
`{date:FORMAT}`	File creation date in a custom moment.js format. Example: `{date:DD-MM-YYYY}` → `08-01-2026`.
`{filename}`	File basename without `.md`. Example: `meeting-notes`.
`{propertyName}`	Live value of that frontmatter property on the current note (new in v0.20.0).

Property placeholders (v0.20.0)

Any token that isn't date / filename and doesn't contain : or whitespace is treated as a frontmatter property lookup. So {g_excerpt}, {summary}, {kebab-case-prop} all work.

Copy a value from one property to another:

IF property: g_excerpt exists
THEN ADD property excerpt: "{g_excerpt}"

Behavior:

Missing property → empty string. No errors, no literal {name} left behind in your YAML.
Arrays are joined with , . A source like tags: [a, b, c] becomes a, b, c in the expanded string.
Earlier actions in the same rule are visible to later ones. The expansion reads from the in-progress frontmatter, so if action #1 sets excerpt, action #2 can reference {excerpt}.
Reserved names win. {date} and {filename} are resolved first; a property literally named date or filename won't shadow them.