[Bug]: Generated default .base views use strict equality for the task identification property, hiding tasks whose property is a list

[GlebYavorski]

Bug Description

When task identification is configured via a frontmatter property (e.g. type: task), the plugin core correctly recognizes tasks whose identification property is a list containing the configured value (e.g. type: [task, AI]). However, the generated default .base views filter with strict equality, so such tasks silently disappear from every default Bases view (Task List, Agenda, Kanban, Calendar).

The two identification paths are inconsistent:

• Plugin core — isTaskFrontmatter() in src/utils/taskIdentification.ts explicitly handles list values:

  if (Array.isArray(frontmatterValue)) {
      return frontmatterValue.some((val: unknown) =>
          compareTaskPropertyIdentifierValue(val, propValue)
      );
  }

  So a note with type: [task, AI] is a valid task for the edit modal, inline widgets, etc. List values in the identification property are an intended, supported case — [Bug]: Saving task modal removes additional list items from task identification property #1051 (fixed in 4.8.0) made the task modal preserve additional list items in exactly this scenario.

• Generated Bases views — generateTaskFilterCondition() in src/templates/defaultBasesFiles.ts emits strict equality:

  return `${propertyRef} == "${escapeBasesStringLiteral(propertyValue)}"`;

  which produces note["type"] == "task" in tasks-default.base, agenda-default.base, etc. In Bases, == against a list value never matches, so the task vanishes from all generated views.

Expected: a note that the plugin itself identifies as a task should also match the filters in the default .base views it generates.

Suggested fix: generate a list-tolerant condition, e.g. list(note["type"]).contains("task") — Bases' list() coerces a scalar to a single-element list, so this matches both type: task and type: [task, AI] with exact element comparison (no substring false positives). This would be analogous to the boolean special-casing already added to the same generator for #1491.

Steps to Reproduce

1. Settings → TaskNotes → Task identification: property, name type, value task (defaults).

2. Create a task; confirm it appears in the default Task List view (TaskNotes/Views/tasks-default.base).

3. Edit the task's frontmatter so the identification property becomes a list that still contains the configured value:

   type:
     - task
     - AI

4. The task disappears from all default Bases views (and from obsidian base:query against them), while the plugin still treats the note as a task (e.g. the task edit modal opens for it).

5. Revert to scalar type: task — the task reappears.

Affected Task Frontmatter

---
status: open
priority: 3-high
type:
  - task
  - AI
scheduled: 2026-08-15
---

Relevant Bases File Content

Generated filter in TaskNotes/Views/tasks-default.base:

filters:
  and:
    - note.type == "task"

Relevant Settings or Customizations

{
  "taskIdentificationMethod": "property",
  "taskPropertyName": "type",
  "taskPropertyValue": "task"
}

TaskNotes 4.11.1, Obsidian with core Bases plugin enabled.

Related Issues

• [Bug]: Saving task modal removes additional list items from task identification property #1051 — task modal used to strip additional list items from the identification property (fixed in 4.8.0), confirming list values are a supported scenario.
• [Bug] or [FR]: Weird mismatch in recognition of boolean property value #1491 — a similar representation mismatch (boolean vs string) in the same generated filter, fixed inside generateTaskFilterCondition().