Param showing data output from history, but not dataset (ie multiple outputs) nor collections

Hi,
I want to specify an input parameter that allows selection of one and only one output from the history. I read the XML specifications, but still don’t know how to fulfill this goal.
Thanks for reading.

1 Like

True, the input selects for tools are designed to allow end users to pick the input as one dataset, multiple datasets (individual), or multiple datasets (collection). To not allow multiple/collections selects will limit the utility of the tool.

Some tools consume all inputs into the same job but most run in “batch mode” (one job per input). Maybe batch mode would be meet your goals? It is the default behavior and is how most tools function.

https://docs.galaxyproject.org/en/master/dev/schema.html#tool-inputs-section

I asked at the Galaxy Gitter channel to make sure this is all correct and there isn’t some other method. Please join in there or just follow along: https://gitter.im/galaxyproject/Lobby?at=5c1012c4f992693c7a5b1fe2

@SamGG can you give us a use case? type="data" should to exactly this. By default the input is only one file. A use is not able to pass multiple files to one job-instance of this tool.

1 Like

Hi. I would like that the end-user is not tempted by the middle or the right button (capture below). So, I would like to propose a simple popup menu (aka select) filled with a list of SMILES chemical results. The processes are very simple: one smi input or a set of parameters, one smi output and a HTML report. There is no reason to process many files at once.
In the following capture, I would like to get only the menu, or the buttons with only the leftmost activated, or any way to select only one single file from the history.
Hope I am clear.
fdb2cfc0-59e7-4773-bd87-490e9ba171b1

@SamGG I understand that the additional buttons might be confusing to the user - but its part of the general unified Galaxy UI between tools. And once users learned what it means it would be confusing if special tools allow/disallow these buttons. Just to make sure I understood your usecase - you only want to process one-job-at-a-time. Means you take one SMILES file and e.g. convert it to InChI. That should still work isn’t it? You are just worried about confusion? The additional buttons are actually giving more power to the user, without scarifying the intention of the tool author. E.g in one of my workflow I create 1.000 SMILES files. If I know want to use your tool - I can still use it on all 1000 files at once. Which would not be feasible if we remove those buttons. In my use-case 1000 jobs will be started. So one job still just take one SMILES file.

@bjoern.gruening Hi Bjoern, you get my point. I am worried about the fact that the processing we set up is quite intensive and has no reason to be applied on many smi files at the same time. It would be OK if I can check that the user has selected only one single file. Can this be achieved using a validator statment?
Best.

We need to distinguish between different layers here. On the tool level - what a tool developer can control in the XML file - you have done a good job. You made sure that only one file can be processed at a time. its not possible to put multiple files into one job. Now you want to avoid that a single user can submit many jobs, aka run your tool on 1000 individual datasets, producing 1000 of different jobs, right? This is to be controlled on the Galaxy Admin level. So the Galaxy admin, that worries about computational load can set this. You can say a user is only allowed to submit 3 concurrent jobs etc … or you can say this tool get a lower priority on your cluster. Which means a user can still submit 1000 of jobs but they will be processed with a lower priority. There are multiple of these setting to keep the load not to high on our cluster. The important thing here is, that these are different level: 1) tool level - defining an interface, and 2) Admin level keeping the cluster load reasonable.

Please let me know if this is unclear, I know my explanations can be bad :frowning:

1 Like

Thanks for your quick feedback. It’s clear. I can not go any further using the tool definition and Galaxy manages smoothly the job submission for a single input or multiple ones. I have to learn more about collections.

Your explanations can not be bad, you are the Gordon Smyth of Galaxy :slight_smile: