Support non-editable workflows

[poautran]

In GitLab by @woutdenolf on Jan 10, 2026, 17:19 GMT+1:

For several use cases (bes, ewoksid31, ewoksid29, ewoksmx etc.) we are moving towards workflows shipped with the ewoksapps libraries.

Ewoks itself supports for load/execute/show like this

ewoks show "ewoksid29.workflows.ambigator_run" -o representation=json_module

ewoks show "ambigator_run"  -o root_module="ewoksid29.workflows"

ewoks show "ambigator_run" -o representation=json_module -o root_module="ewoksid29.workflows"

In ewoksserver, all workflows as JSON files in the backend and these workflows have an identifier which is the file name as well.

What we would need:

• Support loading and executing workflows from ewoksapps libraries.
• Editing of these workflows should not be allowed.
• Button to discover workflows and workflows discovery on server startup. So very similar to task discovery.

Migrated from GitLab: https://gitlab.esrf.fr/workflow/ewoks/ewoksserver/-/issues/72

[poautran]

In GitLab by @woutdenolf on Jan 10, 2026, 17:23 GMT+1:

About current workflow identifiers in ewoksserver:

• workflow identifier is equal to the file name.
• workflow identifier is equal to the graph attribute id.

So that's a duplication. For example PUT /workflow/{identifier} takes a JSON workflow and if identifier != workflows["graph"]["id"] that we get a 400 error.

The id in the graph attribute is used for logging and ewoks events.

The file names are used to read, delete and list workflows.

[poautran]

In GitLab by @woutdenolf on Jan 10, 2026, 17:35 GMT+1:

The workflow ewoksid29.workflows.ambigator_run has

• file name ambigator_run.json
• workflows["graph"]["id"] = workflow_ID29ESRF_ambigator_run

These are no equal and the scope is the ewoksid29 package. Neither is guaranteed to be unique in the scope of ewoksserver.

So the question is, what would be the id in the scope of ewoksserver?

Should we change the way we handle workflow id's in ewoksserver overall and decouple them from graph id's? That could lead to confusion when debugging. Also the id's in the ewoks events need to be the same as the workflow id's in the server I think.

Ewoksserver could load the workflows instead of letting the worker load them. In that case it could change workflows["graph"]["id"] when executing to the ewoksserver id. To be discussed.