GitHub user eugenegujing created a discussion: What should "Import Workflow" do?
## Background
The workspace toolbar has an "Import Workflow" button that loads a workflow
JSON file into the currently opened workflow. Its behavior is surprising and, I
believe, partly buggy (reported in #6846): besides replacing the canvas
content, it fabricates the workflow's metadata from scratch — it sets `wid` to
undefined and renames the workflow to the imported file's name, and it resets
`description` and the published state.
The `wid: undefined` part has clear bad consequences. The auto-persist that
fires after the import sends no wid to `/workflow/persist`, so the backend
inserts a brand-new workflow: every import silently adds a duplicate workflow
to the user's list, and the editor's URL silently switches to that duplicate.
Meanwhile the originally opened workflow's shared-editing session was already
mutated by the import, so the user ends up with two workflows carrying the
imported content — the original (under its old name) and the duplicate (named
after the file). This part is a plain bug and #6846 tracks it.
## The question for the community
Fixing the duplicate requires deciding what the import's intended semantics
are, and that is a user-facing behavior change, so I would like to hear
opinions before finalizing it.
## My proposal
Import should replace only the content of the currently opened workflow, and
everything else should stay as it is in that workflow: keep its `wid` (so
auto-persist updates it in place instead of inserting a duplicate), keep its
name (no more renaming to the file name), and keep its `description` and
published state (today they are silently reset — importing into a published
workflow unpublishes it).
Concretely, the imported workflow object would be built as `{
...getWorkflowMetadata(), content: importedContent }` instead of a fabricated
object. The pre-import content remains recoverable through the version history,
since the in-place save records a version like any other edit.
In addition, I think a confirmation UI is necessary. Since import directly
overwrites the canvas, a user who already has content in the current workflow
should see a dialog telling them the existing content will be overwritten by
the imported file, and the import should proceed only after they confirm. If
the current workflow is empty, the import can proceed without asking. Today
there is no warning at all — one click silently destroys the current canvas.
Two consequences worth calling out:
1. Import no longer renames the workflow to the imported file's name. In a
brand-new unsaved workspace, the workflow keeps the default "Untitled Workflow"
name instead of taking the file name.
2. Users who actually want "create a new workflow from a file" are not losing
anything: the dashboard workflow-list page already has an upload button that
does exactly that (single JSON or a zip of several), names the new workflow
after the file, and is unaffected by this change.
## Alternative considered
Make the toolbar import replace the workflow entirely — treat the file as a
whole new workflow that takes over, name included. I don't think this is the
right direction, because the dashboard upload button already provides exactly
that "create a new workflow from a file" feature, and duplicating it inside the
workspace would leave no way to import content into an existing workflow.
I have a working fix with unit tests ready following the proposal above (the
confirmation dialog could be part of the same PR or a follow-up) and will open
a PR referencing this discussion and #6846.
Feedback on the proposal is very welcome.
GitHub link: https://github.com/apache/texera/discussions/6873
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
