Metadata Form Versioning

[SofiaSazonova]

The target features are: Make MFs editable.
But what to do with already attached forms?
Solution: enable versioning of Metadata Forms.

1. Attached MF should be connected with version, not the MF directly
2. If there are attached entities and user edits the parent MF, new version is created
3. Entity owners are notified about new version of MF
4. When no attached MF left for the older version, it's automatically deleted.

[SofiaSazonova]

How to edit MF:

[SofiaSazonova]

Attach MF: Only latest version is available

Edit attached entity:

1. New version if opened for editing, the fields are pre-filled basing on field name, so user can adjust
2. Old attached MF is deleted
3. New created

Delete attached MF: When no attached MF left for the older version, it's automatically deleted.

Delete parent MF: all versions and attached MFs are deleted in cascade. A pop up with confirmation needed in the UI

[noah-paige]

Some Comments/Qs:

• (1) What action publishes a new metadata form/ what properties of the form are editable?
  • If a metadata form is edited for a new description will this publish a new version? Is description editable? Is it only for edits to the form fields?
• (2) Confirming my understanding - When a new form version is created this will
  • New record in metadata_from_version
  • New record(s) in metadata_from_field (there will be no overlap / re-use of form field records between different form versions right?)
• (3) I see both metadata_form_field and attached_metadata_form tables have both metadataFormUri and metadataFormVersionUri in their data model... is this just for easy look up? The one of significance would the the metadataFormVersionUri one right?
• (4) Will enforcement rules be with respect to each version of the metadata form? I think the above makes sense for a change in form fields after the form is in use - but have we thought about a change in enforcement rules after a form is in use?
• (5) Could version be a version Number that is a composite key along with metadataFormUri for readability - and then we can expose version # on the attached form for transparency / better UX
• (6) On the point of 'When no attached MF left for the older version, it's automatically deleted.' - I think it may be easiest to have users manually delete version of forms and have an upper limit of 10 or so versions (this is similar to how IAM Policy Versions work) rather than some scheduled backend running task to garbage collect
• (7) On editing of attached form what do you mean on 'New version if opened for editing, the fields are pre-filled basing on field name, so user can adjust'?

[SofiaSazonova]

(1) Right now the versioning is only about the fields. Visibility is not editable, description is editable without additional problems
(2) No overlaps, fields are duplicated, even if there were no changes in them particulary
(3) Yes, only for look up, I'm still not sure, if I would need both.
(4) Idea was: enforcement is defined for each version, not MF in general
(5) Yes, also thought about it after I finished the writing)) Much better than version URI
(6) No scheduled task needed. Just when the attached MF deleted, we check if there any left
(7) E.g. there were "Field 1" and "Field 2", after editing it became 'Field 1' and 'Test'. When user wants to update the form, in UI the value of v1.Field1 goes to v2. Field2, but v2.Test becomes empty, so user have to fill it

[SofiaSazonova]

After PR-3 what is still ToDo:

• Default version != latest version. Flag or smth? Do we need it?
• Flag to mark, if we need to delete older versions, when no more attached entities left
• Show all attached entities to MF
• Show on 'Metadata Tab' if new version is available