Feature Description
Summary
When identifying tasks by a frontmatter property (Settings → Task identification → Identify tasks by → Property), TaskNotes currently requires both a property name and an exact property value. A note is only recognized as a task when frontmatter[name] === value.
I'd like to be able to identify tasks by the presence of a property key alone, regardless of its value — e.g. treat any note that has a status field as a task, whether its value is open, in-progress, done, or anything else.
Motivation / use case
Many workflows use a single frontmatter field (like status) whose presence is what marks a note as actionable, while the value is meaningful state that changes over time. Requiring a fixed value forces either:
- a second, redundant identifying field, or
- listing every possible value, which isn't supported.
This is a common pattern in other task tools. For example, TaskForge lets you filter by a property's existence without pinning it to a specific value:
Proposed behavior
Leave the Task property value field empty to mean "match any value": a note is a task whenever the configured property key is present with a non-empty value. When a value is provided, behavior is unchanged (exact match, including the existing array-some and boolean handling).
This mirrors the semantics TaskNotes already uses in its generated Bases filters and .base view files, where an empty value produces an "exists / not empty" condition (note["<prop>"] && note["<prop>"] != "" && note["<prop>"] != null) rather than an equality check — so the detection path and the Bases path would become consistent.
Notes
- "Present" means a non-empty scalar, a non-empty/non-whitespace string, or a non-empty array — an empty
status: (or null) would not count as a task, matching the existing Bases filter.
- No new settings/UI surface required — just the existing Task property value field left blank, with its help text updated to explain the empty = match-any behavior.
I have a working implementation for this and am happy to open a PR referencing this issue.
Feature Description
Summary
When identifying tasks by a frontmatter property (Settings → Task identification → Identify tasks by → Property), TaskNotes currently requires both a property name and an exact property value. A note is only recognized as a task when
frontmatter[name] === value.I'd like to be able to identify tasks by the presence of a property key alone, regardless of its value — e.g. treat any note that has a
statusfield as a task, whether its value isopen,in-progress,done, or anything else.Motivation / use case
Many workflows use a single frontmatter field (like
status) whose presence is what marks a note as actionable, while the value is meaningful state that changes over time. Requiring a fixed value forces either:This is a common pattern in other task tools. For example, TaskForge lets you filter by a property's existence without pinning it to a specific value:
Proposed behavior
Leave the Task property value field empty to mean "match any value": a note is a task whenever the configured property key is present with a non-empty value. When a value is provided, behavior is unchanged (exact match, including the existing array-
someand boolean handling).This mirrors the semantics TaskNotes already uses in its generated Bases filters and
.baseview files, where an empty value produces an "exists / not empty" condition (note["<prop>"] && note["<prop>"] != "" && note["<prop>"] != null) rather than an equality check — so the detection path and the Bases path would become consistent.Notes
status:(ornull) would not count as a task, matching the existing Bases filter.I have a working implementation for this and am happy to open a PR referencing this issue.