I expect the frontend already to check that my study has at least one computational service and no dynamic services before allowing me to create a function.

[bisgaard-itis]

When creating a function from the frontend we should check if the study is suitable for converting it into a function.
I believe the following are the things that need to be checked in order for it to make sense to convert a study into a function:

• The study should contain at least one parameter or probe. (see also I expect the frontend already to check that my study has at least one computational service and no dynamic services before allowing me to create a function. #1940 (comment))
• The study should contain no dynamic services
• The study should contain at least one computational service.

One could do such a check in the backend. I don't see any advantage in doing it in the backend right now, but let me know if you think that would be better @odeimaiz.

[odeimaiz]

@bisgaard-itis You might also want the frontend to check that they are connected...
Can the project have parameter(s) and no probes or only probe(s) and no parameters?
Do all parameters and probes need to be connected?
Do all computational services need to be interconnected?

[bisgaard-itis]

@bisgaard-itis You might also want the frontend to check that they are connected... Can the project have only parameters or only probes? Do all parameters and probes need to be connected? Do all computational services need to be interconnected?

@wvangeit I think you have more experience with running these types of functions/pipelines. Would it make sense to do these additional checks?

[wvangeit]

Wrt to interconnected comp services. I would say not to check for that. People might leave a box open, and i don't think it will generate an error in the backend. Some for not connected probes/parameters, people might have them as a placeholder if they are designed several types of functions.
Wrt to only parameters and probes, nothing in the functions api would stop people from doing that. It looks a bit weird, but maybe we shouldn't exclude it because we might regret it in the future? I guess a comp service could have a side effect that doesn't end up in a probe, but might still be useful.

[odeimaiz]

Wrt to interconnected comp services. I would say not to check for that. People might leave a box open, and i don't think it will generate an error in the backend. Some for not connected probes/parameters, people might have them as a placeholder if they are designed several types of functions. Wrt to only parameters and probes, nothing in the functions api would stop people from doing that. It looks a bit weird, but maybe we shouldn't exclude it because we might regret it in the future? I guess a comp service could have a side effect that doesn't end up in a probe, but might still be useful.

Could you please rewrite the issue description?

[bisgaard-itis]

Wrt to interconnected comp services. I would say not to check for that. People might leave a box open, and i don't think it will generate an error in the backend. Some for not connected probes/parameters, people might have them as a placeholder if they are designed several types of functions. Wrt to only parameters and probes, nothing in the functions api would stop people from doing that. It looks a bit weird, but maybe we shouldn't exclude it because we might regret it in the future? I guess a comp service could have a side effect that doesn't end up in a probe, but might still be useful.

Could you please rewrite the issue description?

Done