About the Contributor

Type of Contribution

This is a Feature

New Behavior

This lays the groundwork for 'overrides'.

As far as I am aware, the backend portion of this is implemented, and works.
Large portions of the ingest flow have been rewritten/refactored to achieve this, which has resulted in this being a very large change.

Currently, this exposes a user action for the user facing operations, but no ui to trigger it

Note: naming of the feature and methods is not final, and might still be changed.

The core of this feature is that blueprints have a new method that they can optionally implement called processIngestData.
This method serves a few purposes:

1. It lets the blueprints perform some pre-processing of the IngestRundown. It can split/merge/invent Parts or Segments, or copy data between them without worrying about impacting ingest performance. Changes are tracked to minimise what needs to be run through getSegment.
   As part of this, it is now the responsibility of this method to ensure that ingest changes are pulled into the IngestRundown correctly. There is a method context.defaultApplyIngestChanges which can do this for you, or you can customise the behaviour by doing something different.
2. It lets the blueprint apply some 'user operation'/'user edit' onto the IngestRundown. How this gets done and persisted is entirely up to the blueprint. It needs to figure that out, and figure out persistence when other ingest changes are made (if persistence beyond that is even wanted).

As a side effect of this, the grouping of MOS stories into segments has been rewritten to be another method that can be used inside of processIngestData. If implementing the method, the mos grouping will have to be applied manually when desired.

If processIngestData is not implemented, core uses the default implementation of, which will match previous behaviour:

export async function processIngestData(
	context: IProcessIngestDataContext,
	mutableIngestRundown: MutableIngestRundown<any, any, any>,
	nrcsIngestRundown: IngestRundown,
	previousNrcsIngestRundown: IngestRundown | undefined,
	ingestChanges: NrcsIngestChangeDetails | UserOperationChange<any>
): Promise<void> {
	if (ingestChanges.source === 'ingest') {
		// Match default grouping, this can be customized to group parts differently
		const groupedIngestRundown = context.groupMosPartsInRundownAndChangesWithSeparator(
			nrcsIngestRundown,
			previousNrcsIngestRundown,
			ingestChanges,
			';' // Match the default separator
		)

		// Standard apply ingest changes
		context.defaultApplyIngestChanges(
			mutableIngestRundown,
			groupedIngestRundown.nrcsIngestRundown,
			groupedIngestRundown.ingestChanges
		)
	} else {
		// TODO: handle user operation
	}
}

The user operations are triggered by a new userAction executeUserChangeOperation. Where this is used and the exact payload is not very well defined yet, that will be done as part of figuring out the ui design.

Testing Instructions

Time Frame

Other Information

This should be squashed when merging.
When contributing upstream, it will need to be broken up into multiple smaller PRs so that each chunk can be reviewed and merged independently. I have a rough plan on how it can be broken up for that

There is an example crude simple ui prototyped at feat/blueprint-processIngestData...bbc:sofie-core:wip/user-overrides-ui
This adds some context menu options for parts and segments:

And a form driven one:

Status

• PR is ready to be reviewed.
• The functionality has been tested by the author.
• Relevant unit tests has been added / updated.
• Relevant documentation (code comments, system documentation) has been added / updated.