Properties format is not updated when converting text type to list type

[Zodian]

Steps to reproduce

1. Create a text type property in a note and add a value.
2. Change the property to list type.

The issue becomes apparent when using the property in Bases with a list function, for example property.filter(value == true). This will result in the error "Error: Cannot find function ""filter"" on type String". When this is used in a Bases filter, the filter will not be evaluated when there is a note with an incorrectly formatted property.

Did you follow the troubleshooting guide? [Y/N]

Yes.

Expected result

The property should be converted correctly to list format when its type is changed from text to list. As a result, list functions in Bases should work correctly with this property.

The property should be saved as:

---
property:
  - value
---

This does happen when adding a new value to the list type property through the UI, which forces the property to be reformatted correctly.

Actual result

The property is displayed as list type in the UI, but the frontmatter is never updated to the correct format. Therefore, using this property with list functions in Bases returns an error.

The property is actually saved as:

---
property: value
---

Environment

SYSTEM INFO:
Obsidian version: 1.12.7
Installer version: 1.12.7
Operating system: Darwin Kernel Version 25.5.0: Mon Apr 27 20:38:56 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6000 25.5.0
Login status: logged in
Language: en-GB
Catalyst license: none
Insider build toggle: off
Live preview: off
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on

---

Additional information

See the following post for more context:

Make Bases 'contain' catch properties even if not exactly that value

Use case or problem I want to be able to use bases to find notes that contain a certain text value in a property, but without having to be that exact value. It just needs to contain that text value. A use case. I’m a farmer and have organized crops according to the time I sow them, time I plant them etc. One crop can have in its “sowing-time” property the values “1 ultimo january”, “2 february” and “3 medio march” (as a list property) I want to be able to pull up a base with all the crops I c…

[excalibud]

To add to this, this bug creates inconsistencies in Base views between a property’s property type (native to Obsidian Properties) and a property’s data type (native to Obsidian Bases).

Steps to reproduce

• In a Sandbox vault, create a note N1 with text property prop: test
• Create a new note N2, add prop, change the property type of prop to list, add some content
• Create a new base and display prop
• Create a new formula in the Base prop type: prop.isType("list") and display it in the Base
• The base column for prop type shows prop as a list type for N2 but not N1
• But the base column for prop implies prop is a list in both N1 and N2 by (1) showing the list icon in the column header and (2) displaying an x after the text test for N1 as if it’s a list item

If there is some intended reason for not automatically changing the YAML for a text property after its type has been changed to list so that the YAML itself is consistent with the list property type, then there should at least be visual indications of the conflict between the property’s registered property type and the property type implied by its YAML formatting. Such visual indications should apply to viewing the property in both notes and Bases.

For instance, if a property has registered type list but has YAML formatting of type text in note N, then something like a “!” badge could be displayed on the upper right of the property icon in N. In a Base view, the “!” badge could be displayed on the property icon in the column header (if displayed in the Base), or even better, only on the rows of the column corresponding to notes where the YAML formatting is inconsistent.