Bulk Insert Missing Fields does not respect fieldsOrder in fileClass

[ALegendsTale]

Steps to reproduce issue:

1. Create new fileClass
2. Add mulitple fields
3. Change order of fields
4. Bulk insert missing fields into new file
5. Fields are inserted in order created instead of modified order

Release Version: 0.8.3

[Truncated]

Is the fieldsOrder intended to apply to the order of the properties in the target notes, or only in the order shown in the FileClass Fields configuration views?

I'd like it to, but I can't find any evidence that it is intended to.

[Truncated]

The experience described originally is confirmed, but it is not exactly:

Fields are inserted in order created instead of modified order

The class definition note body has system properties, but two properties involved here: fields (which is a type of input that is not recognized by core obsidian currently) fieldsOrder (simple array)

Fields are an array of the definitions of the fileClass Properties the user has added, in the order they were added, by property name, example below:

**fields**:
  - name: aliases
    type: MultiFile
    options:
      dvQueryString: dv.pages( '"zz_Meta/Obsidian/Community Plugins"' )
      customRendering: function (page) { return pages.file.aliases; }
    path: ""
    id: Tx3JrE  
  - name: Description
    type: Input
    options: {}
    path: ""
    id: 7uDiRg
  - name: Active
    type: Boolean
    options: {}
    path: ""
    id: HRDUip

fieldsOrder is an array of the ids from fields objects(?) only. The order of the ids in fieldsOrder is directly controlled by the FileClass Fields tab with the Fileclass configuration page arrows.

When using one of the commands to review / add missing frontmatter, a pop-up will appear. In that pop-up, the properties are displayed with the following logic:

1. IF all properties are missing, the order is shown in the pop-up preview with the properties in the order from fieldsOrder.
2. IF any of the properties are NOT missing, they existing ones are shown in the pop-up preview as-is currently at the top, with the rest of the remaining missing properties below them in the order from fieldsOrder. This second situation is very confusing; I would expect to see the order of the properties maintained to match the fieldsOrder and marked missing, instead of this order change.

When Missing Properties are applied to the FrontMatter, it seems to be using the order in the fields property rather than fieldsOrder property.

Expected Resolutions As I mentioned above, the documentation doesn't really make clear what is expected to happen here, so all I can offer is that my expectation is that:

1. In the fileClass configuration you'd set the order (which is currently supported and seems to work to move values for fieldsOrder, though I haven't tested that completely).
2. That order would be consistantly applied to all notes with the fileClass assigned to it automatically. Furthermore, adding "missing" metadata should always insert any missing properties so that the result matches the order in fieldsOrder.
3. Furthermore, I would really like changes to the property order in the fileClass configuration to be automatically reflected in existing notes, or at least have some API call where I can target the entire vault, sub-folders, or muti-selected files to "sync the property order" to the current fileClass / fileClasses.

Partial Workaround In the class definition note body using source code mode, you can re-arrange the array entries order directly there. This will allow all of the FrontMatter to apply to a new note in the desired order if you don't have any mix of Properties (or if the pre-existing ones happen to be the top ones anyway). It will still be some kind of mix-up for files that have some of the order, or if you were trying to insert a new property in the middle of pre-existing note property lists.

[ChristinWhite]

Yep, I'm constantly moving things up and down in the frontmatter view, I'd love to have better ordering by default.