[Bug]: Non standard recognition of list types in YAML

[aubreyz]

What's the bug?

As far as I know, for list elements, if there is only one element it is completely appropriate YAML to express them as

---
tags: tag1
---

or as

---
tags:
  - tag1
---

The same applies to projects (etc). Obsidian recognises both as a valid tag or project. However tasknotes ignores tags (and projects etc.) entered on a single line completely. This is fine if the tags and projects are processed via Tasknotes only, but becomes an issue if they are processed elsewhere (either manually, or via other plugins which manage properties).

What did you expect to happen?

Single line forms of properties which are lists should be recognised correctly

[jleewastaken]

similar issue but the other way around -- I have several list properties (note type, status, priority, etc.) that are used both in and outside of tasknotes, but tasknotes initializes them as if they're text properties (single line without hyphen)

[aubreyz]

similar issue but the other way around -- I have several list properties (note type, status, priority, etc.) that are used both in and outside of tasknotes, but tasknotes initializes them as if they're text properties (single line without hyphen)

Yes I agree with that. Whatever the case it is highly confusing if there is a disagreement between what Obsidian is recognising as a property and what tasknotes is seeing as a property. For better or worse Obsidian (for the properties used by Tasknotes) is allowing the single line format and not recognising that as invalid, and is assigning that value to the property. And showing it up in bases, the property explorer etc...

The problem might be on the Obsidian side with their conception of a List Type being of a completely different type to a text type, but then not enforcing that themselves. Confusing for users though.

[aubreyz]

OK I tried do do an experiment on a clean vault to figure out what is going on here. I'm not sure this helps but worth noting my observations.

As background we have:
a) my finding on my full vault that list type properties entered on a single line seem to be recognised by obsidian but only variably by tasknotes
b) @jleewastaken notes that Tasknotes seems to initialise what should be list properties as text properties
c) Obsidian itself seems to have a slightly strange and apparently undocumented approach to not enforcing a consistent property type across a vault.

The experiment:

a) I started a fresh vault
b) I created a note with yaml as below

---
mylist:
  - Cat
  - Dog
  - Pig
---

Obsidian correctly identifies this as of type "List"

c) I then installed Tasknotes and created a task with one "properties" and two "contexts" using tasknotes

Both contexts and properties show up as list types in the note and in Obsidian Property explorer

d) I then created a note manually with YAML as below

---
contexts: contexta
projects: "[[Test log]]"
tags:
  - task
---

Bizarrely Obsidian recognises projects and contexts as type "text" in the note (and shows no errors). In the property explorer the property and contexts shows as a list. I really don't think Obsidian should behave this way. If you then go into the obsidian properties explorer and change the property type of projects and context to type "text" then again it shows no error, but just shows the property type as different in the two notes.

However in contrast to the experiment in my own (very complex) vault, both contexts and projects in the single line form are recognised by tasknotes perfectly well. It also does not seem to be the case as @jleewastaken finds that Tasknotes is incorrectly initialising the properties.

Summary: I have no clear idea what is going on, and Obsidian should be more rigorous, but I suggest closing this issue for the moment but leave it here in case someone discovers similar issues in their vault.

[callumalpass]

Thank you for all your investigation here @aubreyz . Very much appreciated.

TaskNotes uses Obsidian's API for reading and writing the frontmatter of notes, so there's little that we can do here.

As for @jleewastaken problem--it would be nice to be able allow the users to set the "type" that each properties are. But this would add a lot of complexity for, as I see it, minimal UX improvement. Supporting multiple types for key properties (like status, priority) would add, unfortunately, excessive maintenance burden.