chore: fix inconsistencies in Manipulating Ingest Data documentation

packages/blueprints-integration/src/documents/pieceGeneric.ts

@@ -15,11 +15,13 @@ export interface IBlueprintDirectPlayBase {
 	type: IBlueprintDirectPlayType
 }
 export interface IBlueprintDirectPlayAdLibPiece extends IBlueprintDirectPlayBase {
+	/** Copy the Piece and insert it dynamically at the playhead, as if it were an adlib */
 	type: IBlueprintDirectPlayType.AdLibPiece
 }
 export interface IBlueprintDirectPlayAdLibAction extends IBlueprintDirectPlayBase {
+	/** When direct playing a Piece execute a specified AdLib Action */
 	type: IBlueprintDirectPlayType.AdLibAction
-	/** Id of the action */
+	/** Id of the action to be executed when user requests to direct play a Piece */
 	actionId: string
 	/** Properties defining the action behaviour */
 	userData: ActionUserData
@@ -69,7 +71,7 @@ export interface IBlueprintPieceGeneric<TPrivateData = unknown, TPublicData = un
 	/** User-defined tags that can be used for filtering adlibs in the shelf and identifying pieces by actions */
 	tags?: string[]
 
-	/** Allow this part to be direct played (eg, by double clicking in the rundown timeline view) */
+	/** Allow this piece to be direct played (eg, by double clicking in the rundown timeline view) */
 	allowDirectPlay?: IBlueprintDirectPlay
 
 	/**

packages/blueprints-integration/src/ingest.ts

@@ -125,11 +125,17 @@ export interface UserOperationTarget {
 }
 
 export enum DefaultUserOperationsTypes {
+	/** Revert changes made to a Segment and return it to the state it has inside of the NRCS */
 	REVERT_SEGMENT = '__sofie-revert-segment',
+	/** Revert changes made to a Part and return it to the state it has inside of the NRCS */
 	REVERT_PART = '__sofie-revert-part',
+	/** Revert changes made to a Rundown and return it to the state it has inside of the NRCS */
 	REVERT_RUNDOWN = '__sofie-revert-rundown',
+	/** Update properties of an item using an interactive form defined inside of `userEditProperties` */
 	UPDATE_PROPS = '__sofie-update-props',
+	/** Import a MOS object into a Part - only supported on Parts */
 	IMPORT_MOS_ITEM = '__sofie-import-mos',
+	/** Retime a Piece / move it into a different Part - only supported on Pieces */
 	RETIME_PIECE = '__sofie-retime-piece',
 }
 

packages/documentation/docs/for-developers/for-blueprint-developers/manipulating-ingest-data.md

@@ -18,7 +18,7 @@ function processIngestData(
 	changes: NrcsIngestChangeDetails | UserOperationChange
 ) {
 	if (changes.source === 'ingest') {
-		blueprintContext.defaultApplyIngestChanges(mutableIngestRundown, nrcsIngestRundown, changes)
+		context.defaultApplyIngestChanges(mutableIngestRundown, nrcsIngestRundown, changes)
 	}
 }
 ```
@@ -55,7 +55,7 @@ function processIngestData(
 		const groupedResult = context.groupMosPartsInRundownAndChangesWithSeparator(
 			nrcsIngestRundown,
 			previousNrcsIngestRundown,
-			ingestRundownChanges.changes,
+			changes,
 			';' // Backwards compatibility
 		)
 
@@ -107,13 +107,11 @@ You can of course do any portions of this yourself if you desire.
 
 In some cases, it can be beneficial to allow the user to perform some editing of the Rundown from within the Sofie UI. AdLibs and AdLib Actions can allow for some of this to be done in the current and next Part, but this is limited and doesn't persist when re-running the Part.
 
-The idea here is that the UI will be given some descriptors on operations it can perform, which will then make calls to `processIngestData` so that they can be applied to the IngestRundown. Doing it at this level allows things to persist and for decisions to be made by blueprints over how to merge the changes when an update for a Part is received from the NRCS.
-
-This page doesn't go into how to define the editor for the UI, just how to handle the operations.
+Rundowns, Segments, Parts and Pieces can declare supported operations (via the optional [`userEditOperations`](https://sofie-automation.github.io/sofie-core/typedoc/interfaces/_sofie-automation_blueprints-integration.IBlueprintPiece.html#usereditoperations) property). As these operations are requested by the User in Sofie, Sofie will then make calls to `processIngestData` so that they can be applied to the IngestRundown. Doing it at this level allows things to persist and for decisions to be made by blueprints over how to merge the changes when an update for a Part is received from the NRCS.
 
-There are a few Sofie defined definitions of operations, but it is also expected that custom operations will be defined. You can check the Typescript types for the builtin operations that you might want to handle.
+You can check the TypeScript types for the builtin operations that you might want to handle - they are definied in the [`DefaultUserOperationsTypes`](https://sofie-automation.github.io/sofie-core/typedoc/enums/_sofie-automation_blueprints-integration.DefaultUserOperationsTypes.html) enum.
 
-For example, it could be possible for Segments to be locked, so that any NRCS changes for them are ignored.
+For example, it could be possible for Segments to be locked, so that any NRCS changes for them are ignored. Inside of processIngestData this can be achieved like so:
 
 ```ts
 function processIngestData(