You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Import/Export dialogs are scattered throughout the UI, and would benefit from centralization.
Import functions rely on the user to provide the correct JSON file, and only do cursory schema verification.
Including type and version metadata in exported files lets us build a centralized one-size-supports-all import dialog.
Architectural vision
We could leave export buttons in specific actions, or build a centralized export overview with a multiselect tree of included items. This is something best evaluated with a proof of concept.
Exported files contain an array of objects. The overhead for single item exports is negligible, and this makes it much more convenient to export entire setups.
When importing, we can display a confirmation multi-select with all objects detected in the file.
Each object includes type and version metadata, to allow for mixed exports.
During exports, all ID properties are replaced with variable placeholders (eg. {{LONG_ID}}, {{SHORT_ID}}, {{SPARK_SERVICE}}, {{DASHBOARD_ID}}). The export function has to be type-aware to handle replacement while keeping references intact, but the import function can scan the entire JSON string, and replace all occurrences with new UIDs.
References to non-random IDs like Spark services and dashboards can be grouped. It can be assumed that if an export contains 5 blocks all belonging to the same service, they should also be imported as 5 blocks on a single service.
When exporting block widgets, it should be suggested to also export the block itself, as the widget has very little configuration.
Types supporting export:
widgets
blocks
layouts
system config
setpoint profiles
sessions
Dashboards and services do not need to be directly exportable.
When importing widgets, the user can choose whether to place them on an existing dashboard, or create a new one.
When importing blocks, the user can only choose from pre-existing services, as services are typically discovered, and not created.
The text was updated successfully, but these errors were encountered:
Reasoning
Import/Export dialogs are scattered throughout the UI, and would benefit from centralization.
Import functions rely on the user to provide the correct JSON file, and only do cursory schema verification.
Including type and version metadata in exported files lets us build a centralized one-size-supports-all import dialog.
Architectural vision
We could leave export buttons in specific actions, or build a centralized export overview with a multiselect tree of included items. This is something best evaluated with a proof of concept.
Exported files contain an array of objects. The overhead for single item exports is negligible, and this makes it much more convenient to export entire setups.
When importing, we can display a confirmation multi-select with all objects detected in the file.
Each object includes type and version metadata, to allow for mixed exports.
During exports, all ID properties are replaced with variable placeholders (eg.
{{LONG_ID}}
,{{SHORT_ID}}
,{{SPARK_SERVICE}}
,{{DASHBOARD_ID}}
). The export function has to be type-aware to handle replacement while keeping references intact, but the import function can scan the entire JSON string, and replace all occurrences with new UIDs.References to non-random IDs like Spark services and dashboards can be grouped. It can be assumed that if an export contains 5 blocks all belonging to the same service, they should also be imported as 5 blocks on a single service.
When exporting block widgets, it should be suggested to also export the block itself, as the widget has very little configuration.
Types supporting export:
Dashboards and services do not need to be directly exportable.
When importing widgets, the user can choose whether to place them on an existing dashboard, or create a new one.
When importing blocks, the user can only choose from pre-existing services, as services are typically discovered, and not created.
The text was updated successfully, but these errors were encountered: