feat: blueprint config fixup step SOFIE-2258

[Julusian]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

feature

This builds on #1049

I am not entirely convinced by the naming, so am open to suggestions on a better name

• What is the current behavior? (You can also link to an open issue here)

When using the new blueprint config upgrade flow #808 instead of the old migrations flow, it is not possible to handle restructuring of the config without some external tooling or manual fixup of the data.

• What is the new behavior (if this is a feature change)?

It is now possible to provide a method to perform some fixup of the users configuration overrides.
This method is optional, and if defined must be run after uploading blueprints before the config can be edited or re-validated.

It has been added as an explicit step as it has the ability to show warning messages to the user, some of which might need manual addressing. It is also possible to ignore/skip the run of fixupConfig, intended to be an escape hatch in case the fixupConfig function gets stuck in an error loop.
This utilises the changed from #1049 for this, so that the fixup function can be triggered from both the blueprint config page, and from the main migrations page. When the fixup needs running, the configuration section is hidden, to ensure changes are not made.

Once run, it is possible to edit configuration and apply/validate the config as usual.

Because this is modifying an object which is of type ObjectWithOverrides<T>, we don't want to expose it directly to the blueprints. In particular, we don't want to expose every type of operation as that will make it more breaking when we modify/add more operation types. Instead we provide an abstract view of this via the context.
This means the blueprints are aware that the key identifiers are paths, but they must perform mutations via function calls so that we can update the overrides correctly.

• Other information:

Some examples of things that could be done.

Fix a typo in a property name

export function fixUpConfig(context: IFixUpConfigContext<ShowStyleConfig>): void {
	if (context.hasOperations('MediaManagetBasePath')) {
		if (context.hasOperations('MediaManagerBasePath')) {
			// Both exist, discard the incorrect one
			context.removeOperations('MediaManagetBasePath')
		} else {
			context.renameOperations('MediaManagetBasePath', 'MediaManagerBasePath')
		}
	}
}

Status

• Code documentation for the relevant parts in the code have been added/updated by the PR author
• The functionality has been tested by the PR author
• Automated tests to cover the new functionality and/or guard against regressions have been added
• The functionality has been tested by NRK

[codecov]

Codecov Report

Attention: 714 lines in your changes are missing coverage. Please review.

Comparison is base (bcfeb99) 58.05% compared to head (fb5f18a) 57.95%.
Report is 95 commits behind head on release51.

Additional details and impacted files

@@              Coverage Diff              @@
##           release51    #1050      +/-   ##
=============================================
- Coverage      58.05%   57.95%   -0.11%     
=============================================
  Files            485      501      +16     
  Lines          78987    80375    +1388     
  Branches        4130     4248     +118     
=============================================
+ Hits           45855    46580     +725     
- Misses         33077    33741     +664     
+ Partials          55       54       -1     

Files	Coverage Δ
meteor/client/lib/data/util/object-to-xml.ts	94.11% <100.00%> (ø)
meteor/lib/api/client.ts	100.00% <100.00%> (ø)
meteor/lib/api/methods.ts	87.85% <100.00%> (ø)
meteor/lib/api/migration.ts	100.00% <100.00%> (ø)
meteor/lib/api/pubsub.ts	95.85% <100.00%> (+0.06%)	⬆️
meteor/lib/api/userActions.ts	100.00% <100.00%> (ø)
meteor/lib/lib.ts	76.65% <100.00%> (-1.37%)	⬇️
meteor/lib/logging.ts	84.90% <100.00%> (ø)
meteor/lib/userAction.ts	100.00% <100.00%> (ø)
meteor/server/api/blueprints/api.ts	83.87% <100.00%> (+0.24%)	⬆️
... and 83 more

... and 6 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mint-dewit]

Why is the studio config fixup step ran from the worker whereas the showstyle step is ran from meteor?

[Julusian]

Following the pattern I started with the other config methods.

I am not 100% sold on it anymore, but my original justification was that we have the job-worker which handles the studio, and doing it there will avoid needing to load the studio blueprints in meteor.
But a showstyle can be used by multiple studios, so can't be pushed to the job-worker currently.