Fileclass Fields no longer seem to be connected

[brimwats]

Noticed this when I tried to add excluded fields to CFP Reply, which extends and excludes Project

[mdelobelle]

There's something strange happening. Your "fields" property shouldn't be empty. It should contain the field definition that you see in the body of the fileclass file (which was the previous way to define fileclass fields) Those fields should have been migrated from the "body" to the frontmatter "fields" property.

Could you try this: in your Project.md and CFP reply.md: remove the "version" property Disable / enable metadata menu (to force a reindexing that should "migrate" those two classes.

Is the "fields" property now filed with the fields definition?

[totallyGreg]

I am having the same issue where the fields in the body are failing to migrate to the field property.

This fixed worked for me (removing the version and the fields property that was created when I added a new field as a test.

I'll need to do this for every one of my fileClasses however... :/

[brimwats]

This seems like it helps; I should be deleting this field from all 30+ of my classtypes?

[mdelobelle]

I would like more information to guide you in the right direction. Did the fields definition "disappear" from the frontmatter recently? If so did you notice when this happened? I you are using Obsidian sync, could you check the "Sync version history" of your "CFP Reply.md" file and see how the frontmatter "fields" property has evolved over time?

[brimwats]

Did the fields definition "disappear" from the frontmatter recently? If so did you notice when this happened?

I did not. I use syncthing so there is a chance it could have been overwritten with an earlier version.

HOWEVER

Looking at the File Recovery history I see this:

Then on Feb 14th I updated the name of the file to CFP Reply (with a space),

Originally the "extends Project" was there:

then it was removed (not by me I think):

and then the version updated:

I see my attempt to re-add project here:

but it does not update until i deleted the version line and toggled MDM:

[mdelobelle]

Thanks. The version of feb 14th shouldn't have an empty "fields" property and a "version" property set to 2.x at the same time. The fields that you see in the "body" of the fileclass should have been migrated. Maybe this is due to the manual renaming of the fileclass (never tested it on my side)

Deleting the "version" will trigger a migration the next time the index is running.

So if you encounter this situation in other files, deleting the "version" field - if you have the legacy field definitions in the body, and assuming that you didn't add/modify any field in this fileclass later on - should fix the issue.

Could you check if there are any other fileclasses in this situation in your vault?

[brimwats]

Could you check if there are any other fileclasses in this situation in your vault?

They all (around 30 of them) are like that. I haven't deleted the version field yet and I haven't renamed any other of them

[mdelobelle]

Ok. My fear is that the "fields" property may have been emptied by some bug in the code with a recent release.

Could you search in the version history for a fileclass where the "fields" wasn't empty (and the "version" was 2.x) at some point in time and then was empty ("[]") at a later date?

[brimwats]

Unfortunately the only one that has been changed would be Project:

[mdelobelle]

Alright it looks like the migration of fileclasses has failed somehow... Here is the protocol that I recommend:

A. For fileclasses where "field" is empty (no risk of deleting data)

• look for fileClasses where "fields: []"
• remove the "version: 2.x" in those files
• disable/enable the plugin (will force a migration)
• check that the "fields:" is populated with the fields definition contained in the body of the fileclass

B. For fileclasses where "fields:" isn't empty:

• if "version" is >= 2.0 and if the fields definition are the same in the frontmatter and the body: good nothing to do
• if not , can you paste an example?

[brimwats]

look for fileClasses where "fields: []"

There were 60. I deleted the "version" line and toggled plugin. Most of them had the "fields" field correctly added. For some reason it "version" was added back to 13 of them without having "fields" added.

[mdelobelle]

Someone else had the sale issue https://github.com/mdelobelle/metadatamenu/issues/597

I'm doing some other tests. Will keep you posted

[mdelobelle]

https://github.com/mdelobelle/metadatamenu/issues/597#issuecomment-1952932703

I've identified what may have caused the issue. I've released a new version that should prevent that. Unfortunately the recovering process can't be automatized :/