Feat/UI useredit panel

[olzzon]

This is an internal BBC WIP PR for discussion of concepts for the PropertiesPanel and Useredits.
Be aware:

• The panel is currently implemented as a hack in the Notification Center
• The schema of useredits is currently using a simple "select" tag instead of "Schema...." type, mainly because of styling
• Maybe a "button" type of schema like the grouping array, would be cool to have as a schema, this way e.g. Split/DVE selection could be button with SVG icons on them, instead of a list.
• Buttons can be either text or svg's.

The corresponding Blueprints is in this branch:
https://github.com/bbc/eng-ga-sofie-blueprints/tree/feat/user-edits-properties-panel

[Julusian]

I have a disagreement with how this is done, which is simply that I don't think the properties panel should be using the same list of userEditOperations that we added for the context menu.

I think that the properties panel should be using its own dedicated property, which provides the expected schemas for the panel.
Something like:

interface Part {
  ...

  propertiesPanel?: PropertiesPanelSchema

  ...
}

interface PropertiesPanelSchema {
    /** Common properties to show at the top **/
    headerSchema?: JSONBlob<JSONSchema>
    /** Common properties to show at the bottom **/
    footerSchema?: JSONBlob<JSONSchema>

	/** The json schemas describing the form to display */
	schemas: Record<string, UserEditingSourceLayer>
	/** Current values to populate the form with */
	currentValues: {
		type: string
		value: Record<string, any>
	}
    headerValues?: Record<string, any>
    footerValues?: Record<string, any>
}

As I have said in the comments, I think that reusing the userEditOperations is both making the properties panel ui very complex to handle the displaying and queueing of operations, and will easily result in unexpected behaviour when saving changes in the panel.

There are two key cases I am concerned about, which is that the user triggering the 'ACTION' type of operations in a sequence of A, B, A is not guaranteed to be the same as A, B or even B, A and so we can't reliably condense down the sequence of operations.
And even just executing A, B may not be ok as executing A could remove the ability to execute B.

I don't see a reason that these need to be using the same operations, and while them being separate will likely mean more work for the blueprints dev, it means that the properties panel content will be tailored specifically for the panel.
If they want to have a 'lock part' option in both places, they will have to define it for both, but then they can get better behaviour in both places. If there is an option which affects what other options should be shown/allowed, the json schema for the properties panel could (once we add support for these things to the SchemaForm component) show/hide the appropriate options which are dependent on the others.

[Julusian]

Suggested change

	grouping: clone(userEdit.grouping) as UserEditingGroupingType[] | undefined,
	grouping: clone<UserEditingGroupingType[] | undefined>(userEdit.grouping),

hopefully that satisfies the type error?

The casting you had would ignore some other real type errors