Cockpit

AT

Migration page is extended to set variables

Reasoning for UI Design

• There are two concerns of variable validation which are more user friendly to emphasize separately (separation of concerns):
  • Variable validation: the type matches the value; a JSON variable value is valid; etc.
  • Migration Plan validation: the variables are valid in the context of the migration
• A variable can be added and edited, and we need to have migration plan validation no matter which of the operation caused the validation; the variables table currently just indicates an invalid variable with a red background color and the prevention of submitting the variable of the row and does not show more information what exactly is wrong
  • How can the user distinguish if we would reuse the UI here if the problem is related to an erroneous variable definition or invalidity of the migration plan as a whole?
• It is consistent with the flow-node mapping, which shows migration plan validation errors via a popover but let's you still create the mapping (no prevention from creating a mapping)
• A migration plan might be valid in one Cockpit instance but invalid in another Cockpit instance (depending on the configuration of the engine); there is a feature request to make it possible to import/export migration plans between applications; I can imagine that we will add an export button to the feature which should not be disabled when the migration plan is invalid; with the current design decision, achieving this is easily possible
• It is imaginable that we extend the "set variables on migration" feature to allow setting variables into the scopes of flow-nodes; my idea is that variable names can be attached on the flow-node mapping page to flow-node instances, and on the next page, it is possible to complete the variable value, type, etc.; this would require a UI similar to what we have now
  • Also, I can imagine that assigning a variable into a not existing flow-node instance could be another validation criterion that could be indicated in the set variables step
• When a variable is invalid, a popover instead of a tooltip is shown, allowing us to show text more user-friendly than a tooltip that shows everything on one line without line breaks
  • Also, the way I implemented the popover allows us to add more variable validation in the future without touching the frontend again
  • Lastly, we also use popovers on the flow-node mapping step, which makes it consistent. If the variable is valid or currently edited, a tooltip is used since we are only showing a tiny bit of text.