I am new in Obsidian and YAML, but experienced in programming. I have not found a solution if it exist to my problem.
In the YAML block, I would like to use the value (“Doing”) of metadata (Status) to create the tag todo/Doing. In Unix shell, it would be something like that tags: todo/$Status.
My idea is to link the task management with the kanban and Checklist plugins.
When I move a kanban card from the column e.g. “Doing” to “Done”, the Metaedit plugin allows to update the value of the metadata in the the associated note. I would like to use this metadata to update the tag todo/xxx , that is used by Checklist.
Is my question clear enough ?
Is there anybody that could help me or provide me some references to understand how the variables work in the obsidian YAML, and to have some references on the syntax to use ?
Thanks in advance
There are three ways forward, as I see it (surely even more options exists, but these three are the ones I’m going to focus on): Leave the value within that inline field, use api.FileManager.processFrontmatter() to store it, or use the metaedit plugin to store it.
Leave it as is
I’m not quite sure what you gain by moving it from Status: into the tags, and maybe it’s not mine to question. And as I eluded to there might an issue related to changing the file from within itself, and when running a dataview query (or metaedit change), you’ve potentially got an issue with how to trigger, and when to trigger the update of the YAML.
I don’t see how to safely get a trigger to initiate either query just when its changes, and the alternative is that the queries trigger way to often, and change it when it’s not needing to change, and you might end up in a race condition when editing the file between your manual edits, and the changes that either query would want to do.
Finally, for many searches and queries where you would want to use the values of #todo/Doing, you just as easily do as Status = "Doing" or file.Status = Doing, instead of doing something like econtains(file.etags, "#todo/Doing") or similar. So my point being is not that I don’t want to help you, but maybe question whether you really want/need to do this.
So I can’t really give any examples on how to do it, but it should be doable.
This is potentially your best bet to do changes to the frontmatter (another name for the YAML section), but it comes with its own caveats. Firstly, it’s a bit technical and requires some coding experience. Secondly, in the current (official) version of 1.1.9 there is an issue related to empty frontmatter sections (which shouldn’t pose a problem in your case, though).
In the issue above, I present code to actually change the frontmatter using this method, where the focus is on the issue with the empty frontmatter section. Two notes to be made, though, the issue itself is resolved in one of the insider version (which I currently don’t have access to), so the next official version will have that fixed. The second note is that I’ve presented a workaround later on in the same thread.
So once you figure out a safe way to avoid the race condition issue, and potentially how to handle multiple values in tags: and you wanting to change only one of them, this is indeed a plausible way forward.
I don’t have the time for at least a few days, to try suggesting code to solve it, but if you’re a programmer maybe this is enough information to get you going?
I’ve been thinking that possible this could be a way to handle some of the issues:
Add another field like LastStatus into the frontmatter
Whenever Status and LastStatus are identical, bail out and don’t do anything, as the status haven’t changed. (The next points, is therefore only when it has changed)
Prepare a object with the new value for LastStatus, and the new value of todo/...
Send this object into a method called by api.FileManager.processFrontmatter, where you then:
Split the tags field, and remove the old todo/... field, and insert the new value of it, and join up the values again
Update the frontmatter with both values
This should be safe, as processFrontmatter is supposed to be an atomic update of the frontmatter, but I’ve never tried to do it on the current file.