Skip to main content

Prefill Pickers Policies

In this section we will see how the pickers will be prefilled with already existing values, and where the information comes from.

Parameters Saved at Creation time​

With the Editor Wizard feature, we also introduced in witboost the persistence of all the values the user inputs at creation time for a data product or a component. The parameters will be saved inside the catalog-info.yaml under the key witboost.parameters. Here is an 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: {}
# here is the new persisted key
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

This was introduced because the values saved in the catalog-info.yaml can be transformed by Nunjucks (e.g. the ${{ parameters.value }} string), with the consequence that the raw information input by the user is lost. These newly persisted parameters will be used by the editor wizard to prefill pickers, if found. In fact, for old systems/components, that key has not been persisted so it will not be available for the editor wizard. In the following section we will show another method used to prefill pickers in those cases.

note

old Templates will not be affected by this change, so the backward compatibility is always ensured. Witboost will handle the persistence of the new witboost.parameters key for new entities without the need for the platform team to do anything.

info

the editor wizard will always perform the witboost.parameters check first to prefill pickers. It has the highest priority.

Parameters Fetched from Task​

Another way that has been introduced in order to prefill pickers with parameters input by the user is to fetch them from the creation task of the required entity. This is done only if the object witboost.parameters is not present in the entity's catalog-info, so mainly for all the entities created before the editor wizard was introduced. In this case, witboost tries to fetch the task that created the actual entity requested to be edited, searching parameters in the database.

info

There could be cases in which the creation task is not found, for example if the entity you want to edit was imported from outside the scope of your witboost installation. In these cases, we will see next what happens, based on the policy specified.

Policies​

We defined three different policies to prefill pickers, in the app-config.yaml under mesh.builder.scaffolder.editorWizard.prefillPolicy:

  • no_strict: this is the most permissive one. With this policy, even if pickers cannot be prefilled using the methods described above (scenario 1 and 2), the user is allowed to go ahead with the edit operation anyway, and a warning is showed: Warning no prefill
    info

    If no policy is applied by the platform team, no_strict will be applied as default.

  • less_strict: this case allows to user to continue the edit operation only if either scenario 1 or 2 completes successfully. If not (and so pickers would have leaved blank), witboost forces the user back to the entity page, showing a meaningful error. Error less strict Otherwise, if scenario 2 is met, this is what pops up: Warning outofdate params
    note

    Parameters could be out of date because what is prefilled in the pickers are the values inserted at creation time. Those value could have been changed manually by the user later, by directly editing the catalog-info.yaml on git.

  • strict: this is the most restrictive policy. With this, the user can continue the edit operation only if the editing entity has witboost.parameters in its catalog-info.yaml file. So only if scenario 1 is met. In all the other cases, the user will be redirected to the entity page and an error pops up: Error strict