Why is it possible to set required parameters to "not required" ? about dm2e-gui

[kba]

Suppose a pos1 has a required parameter and you want to define a workflow-specific default (say, the organization name or a default XSLT). Then it should be possible to make the workflow parameter optional.

Maybe the logic should be that a workflow parameter without a default cannot be set to non-required?

[d0rg0ld]

But doesn't this rather mean that the parameter is kind of "fixed" or "not fixed" ? If a parameter is "required" by the web service, then it has to be there. If I "hard-code" a default value or not, is IMHO not the question of "required or not required". in other words: probably the "required" radio button has a totally different meaning than the "required" statement in the web service parameter list? then it would be good to find different terms for the radio button!

[kba]

Probably the problem here is that this view mixes model levels. Thinking about it, I think you should not be allowed to change the "required/not-required" state of position parameters. After all, these are defined by the web service descriptions and can lead to workflows using the same web services being incompatible. Edit, that is beyond the point, the UI doesn't allow that anyway, ignore

Instead, workflow input parameters should be used for everything and webs service parameters should not be editable at all:

• To set a fixed, workflow-specific constant, connect position parameter to workflow and set the default value of the workflow parameter and set to non-required
• Any position parameter connected to a workflow without a default value is always required\
• Every workflow with web services that have required input parameters NOT connected to the workflow should result in a warning when trying to save it and refuse the creation of workflow configurations.
• Every workflow with web service output parameters not connected to the workflow or other web service input parameters should result in a warning when trying to save that workflow but allow the creation of workflow configs.

These checks are actually in the backend code but not enforced, we should expose them to the HTTP API.

@kaiec @Dommii Does that make sense to you?

[d0rg0ld]

regarding the "edit parameter" dialog: for me, setting required/not-required currently results in whether you can edit the value in the configuration or not.

So why dont you just call it: "editable/not editable in config" and then, as you suggest, to issue warnings about unmet parameter requirements. So if I set a "required" parameter to "not editable" then it must have a default, otherwise there will be a warning ...

[d0rg0ld]

you once also mentioned to set xslt files as default. but how do I get them into the "edit parameters" dialog?

[kba]

So why dont you just call it: "editable/not editable in config" and then, as you suggest, to issue warnings about unmet parameter requirements. So if I set a "required" parameter to "not editable" then it must have a default, otherwise there will be a warning ...

Even parameters with a default should be editable in the config editor IMHO. That way you can re-use a workflow from another organization e.g.

In the end wouldn't it be easier to get rid of the required/not-required option completely and just enforce that all input parameters in the config editor must be set?

you once also mentioned to set xslt files as default. but how do I get them into the "edit parameters" dialog?

You can't drag and drop them if that's what you mean. We could add the file list view from the config editor to the parameter edit view but that might mislead users to edit the workflow for every new ingestion instead of using different configurations.

[kba]

All parameters are required but the user can set a default value. Though users can override this, this seems the least confusing solution.