Prefill Pickers Policies

When the Editor Wizard is opened, it attempts to preload input fields using values stored in the entity's repository. This ensures users see the current values of the entity they are editing.

This section explains how values are loaded depending on whether the entity is a Skeleton or Legacy entity.

Skeleton entities

For Skeleton Entities, input values are loaded from the entity's parameters.yaml file:

• Each editor field is matched 1:1 by name with a key in the parameters: block of the parameters.yaml.
• If a matching key is found, the value is prefilled into the editor form.

On submit:

• Edited values are merged back into the parameters: section.
• Existing keys with the same name are overwritten.

This process keeps the catalog-info.yaml untouched, as it is dynamically rendered using values from parameters.yaml.

Legacy entities

For Legacy Entities, editable values are stored directly inside the catalog-info.yaml file under the witboost.parameters block.

Example:

apiVersion: backstage.io/v1alpha1
kind: System
metadata:
  name: finance.full_parameters_dp_ok.0
  description: This is full_parameters_dp_ok
  annotations:
    gitlab.com/project-slug: federico.morreale/full_parameters_dp_ok
    backstage.io/techdocs-ref: dir:.
spec:
  type: dataproduct
  lifecycle: experimental
  owner: user:federico.morreale_agilelab.it
  domain: domain:Finance
  mesh:
    dataProductOwner: user:federico.morreale_agilelab.it
    developmentGroup: group:agile_lab
    email: federico.morreale@agilelab.it
    version: 0.1.0-SNAPSHOT-2
    fullyQualifiedName: null
    name: full_parameters_dp_ok
    informationSLA: null
    maturity: null
    useCaseTemplateId: urn:dmb:utm:dataproduct-template:0.0.0
    infrastructureTemplateId: urn:dmb:itm:dataproduct-provisioner:1
    billing: {}
    tags: []
    specific: {}
# parmeters
witboost:
  parameters:
    domain: domain:Finance
    identifier: finance.full_parameters_dp_ok.0
    description: This is full_parameters_dp_ok
    dataProductOwner: user:federico.morreale_agilelab.it
    developmentGroup: group:agile_lab
    email: federico.morreale@agilelab.it
    name: full_parameters_dp_ok
    useCaseTemplateId: urn:dmb:utm:dataproduct-template:0.0.0
    infrastructureTemplateId: urn:dmb:itm:dataproduct-provisioner:1
    useCaseTemplateVersion: 0.0.0
    dataproduct: full_parameters_dp_ok

Prefill logic:

• When the Editor Wizard loads, it searches for matching keys inside witboost.parameters.
• As with skeleton entities, parameter names must match the editor field names exactly.
• These values are shown as prefilled values in the wizard.

On submit:

• The updated values are written back into the witboost.parameters section of catalog-info.yaml.
• The updated parameters are used to render the edit skeleton that is then merged into the entity's catalog-info.yaml.

Fallback: Parameters fetched from creation task

In addition to reading parameters from the entity's local metadata, Witboost also supports pre-filling pickers by retrieving values from the creation task of the entity. This fallback is triggered only if:

• The entity is a Legacy Entity.
• The entity does not have a witboost.parameters block in its catalog-info.yaml — this may occur with entities that were created in earlier versions of Witboost.

In this case, Witboost attempts to locate the original creation task in its internal database and extract the input parameters used at creation time.

info

There may be cases where the creation task cannot be found, such as:

• The entity was imported from outside the Witboost environment.
• The original task data has been purged or lost.
• The entity was created manually without a task.

In such cases, the system behavior will depend on the editor prefill policy defined in your configuration.

warning

Parameters fetched from the creation task could be out of date. Those value could have been changed manually by the user, by directly editing the catalog-info.yaml on Git.

Editor Prefill Policies

Witboost supports three configurable policies for how strictly the Editor Wizard enforces prefill validation. These are set via the app-config.yaml at the following path:

mesh:
  builder:
    scaffolder:
      editorWizard:
        prefillPolicy: <policy>

• no_strict (default): this is the most permissive one. The user is allowed to continue editing even if no parameter values are found via local metadata or the creation task:

  

• less_strict: editing is allowed only if parameters are found using either witboost.parameters or the creation task.

  Parameters inferred from the creation task:

  No parameters found:

• strict: editing is only allowed if the entity has a witboost.parameters block in its catalog-info.yaml