Through out the project there is a connection between the id and the label of a workflow. Some considerations that guided our steps are:
Since both are part of the ewoks workflow model we considered that the id shouldn't be a nonsense generated string but as close as possible to the label which is what the user will assign to the workflow when creating it. Later and when a database is being used maybe a nonsense id is assigned but that wont affect the UI since only label is presented to the user.
id has to be unique
label does not have to be unique and it is what the user sees in the application. That creates some problems since you can have 2 workflows in the dropdown with the same name===label.
So based on the above:
when cloning the user should see the label as a proposed identifier in the dialog menu.
If an attempt is made to save with the same label without pressing overwrite a warning should appear to warn that he will end-up with 2 workflows having the same name in the dropdown.
If he changes the name then the POST will have the
{id: theGivenIdentifier, label: theClonedWorkflowLabel OR theGivenIdentifier}
The second is the case now and for me is the correct since the user cannot see or edit the id of the workflow anywhere in the app.
"Identifier" in ewoks basically means "filename", right? I agree with Loïc that we should embrace this and make it clearer in the UI.
One aspect of this would be to enforce a specific format in the front-end, like limiting the allowed characters to something like [a-zA-Z0-9_-] (no spaces).
That creates some problems since you can have 2 workflows in the dropdown with the same name===label.
This is a problem with the dropdown, not with the fact that labels don't have to be unique. The label is basically just an optional way to format the identifier a bit so it's more readable, like my_workflow => My Workflow.
Wherever duplicate labels create confusion, nothing prevents you from displaying also the ID, just like in VS Code when you open files with the same name but located in different folders:
Typically, the ID should be displayed a bit subtly, either to the right of the label, or underneath it on a separate line.
If an attempt is made to save with the same label without pressing overwrite a warning should appear to warn that he will end-up with 2 workflows having the same name in the dropdown.
Are you talking about editing the label of an existing workflow (i.e. a workflow that has already been given an identifier and saved to the server)? If so, I disagree. Labels don't have to be unique, full stop. Users can update them to whatever they want -- the UI should just be aware that multiple workflows can have the same label as explained above.
If you're talking about saving a workflow for the first time, then of course, if the label is used to pre-fill the ID field and there's a conflict, then the user should get an error when they try to submit the form. They can then just change the identifier, submit the form again, and they're done.
Basically, this is what I have in mind when saving for the first time:
If the workflow has a label, convert the label into an identifier that respects the format above and use that to pre-fill the ID field.
If the workflow doesn't have a label, let the user provide one, while enforcing the format above.
When cloning, just add _copy to the identifier of the workflow being cloned and pre-fill the ID field with that.
Of course, we can be smarter when pre-filling the ID field by pro-actively checking for a conflict and adding a number suffix if needed, but this is really low-priority IMO.
Are you talking about editing the label of an existing workflow (i.e. a workflow that has already been given an identifier and saved to the server)?
I was only referring to cloning not editing the label to an existing workflow. It is POST when cloning so it is like saving a workflow for the first time. Label does not have to be unique.
If you're talking about saving a workflow for the first time, then of course, if the label is used to pre-fill the ID field and there's a conflict, then the user should get an error when they try to submit the form. They can then just change the identifier, submit the form again, and they're done
I agree and that is what happens now when for the new name of the cloned workflow the label is being used for the user to change it as he sees fit.
Basically, this is what I have in mind when saving for the first time:* If the workflow has a label, convert the label into an identifier that respects the format above and use that to pre-fill the ID field.* If the workflow doesn't have a label, let the user provide one, while enforcing the format above.
For now when initially saving a workflow it cannot be saved if the user hasn't provided a label that will be used to create the ID. If the specific label exists it wont be saved for now giving a warning that this workflow exists.
When cloning, just add _copy to the identifier of the workflow being cloned and pre-fill the ID field with that.
Here I suggest in my bullets above to use the label of the workflowToBeCloned in the dialog because it is what the user sees and knows and not the id. He then can edit the name as he sees fit. In that way he may change completely the label and we don't want to have as an id the oldWorkflowID_cloned. Instead we will have theNewLabel_1 (_1 if the given label exists as an id in his workflows. In that case IMO we should also remind him that there is a workflow with this name)
[Axel] Basically, this is what I have in mind when saving for the first time:* If the workflow has a label, convert the label into an identifier that respects the format above and use that to pre-fill the ID field.* If the workflow doesn't have a label, let the user provide one, while enforcing the format above.
[Ioannis] For now when initially saving a workflow it cannot be saved if the user hasn't provided a label that will be used to create the ID. If the specific label exists it wont be saved for now giving a warning that this workflow exists.
Not sure if you are agreeing with the behaviour I'm proposing or not?
[Axel] When cloning, just add _copy to the identifier of the workflow being cloned and pre-fill the ID field with that.
[Ioannis] Here I suggest in my bullets above to use the label of the workflowToBeCloned in the dialog because it is what the user sees and knows and not the id. He then can edit the name as he sees fit. In that way he may change completely the label and we don't want to have as an id the oldWorkflowID_cloned. Instead we will have theNewLabel_1 (_1 if the given label exists as an id in his workflows. In that case IMO we should also remind him that there is a workflow with this name)
I see, so first, what do you think of the _copy behaviour when the workflow being cloned does not have a label?
Now, let's imagine that I have a workflow with ID peel_potatoes and label My awesome workflow for peeling potatoes.
Scenario 1: I want to clone this workflow because I need one for peeling carrots.
Personally, I'd prefer the filenames of my workflows to remain consistent, so I'd probably want the new workflow to be named peel_carrots. Thus, wouldn't it be better for the ID field to be pre-filled with peel_potatoes_copy rather than my_awesome_workflow_for_peeling_potatoes?
Scenario 2: I want to clone this workflow to make a back-up before making further changes, or maybe to prototype another version of the workflow before changing the main file.
Do I want to end up with two workflows named:
peel_potatoes and peel_potatoes_copy, or
peel_potatoes and my_awesome_workflow_for_peeling_potatoes?
IMO, peel_potatoes_copy makes it clear that the workflow is a copy of peel_potatoes, whereas this clarity is lost in the second case.
In both scenarios, I think pre-filling the ID field with the label when cloning is not what users would expect.
At the moment we have id and label in the workflow json description as well as a filename.
id and filename should be the same, unique and are not optional.
label is optional and it is what the user sees in the frontend.
Label can be removed since its purpose was initially to be used as the only thing that the user will interact with while the id would be a random string from a database. Instead in the current implementation we are using only files that can be also accessed in the filesystem so their filename should be readable and aligned with the id within the json. Also the id is being used in the subgraph process as it is unique. With the current situation of not having a DB the label seems to be a redundancy that complicates things.
Using only the id in the frontend and checking its alliance with the filename seems to simplify things.