- If a step has a label, display it in the step editor side panel title.
- Allow clicking the title to change the label.
- Display the label (if set) as the workflow node box title.
- Add icon to workflow node since the title might not be related to type anymore.
- Enforce unique labels accross the workflow in the editor.
- Qunit test cases for some of this behavior and other recent changes.
- Reduce duplication between initializing generic modules and tool modules.
- Switch tool_id to content_id as variable names throughout the client.
- Rename get_tool_id to get_content_id on workflow modules.
- Add some minimal documentation to the workflow module about get_content_id.
Downstream in the subworkflow commit I switch the over-the-wire communication to use content_id instead of tool_id also and use content_ids to refer to workflow ids in subworkflow moduls.
Allow multiple collections to be fed to a multi data parameter in one reduction step. Fixes#750 and will really simplify certain classes of tools.
Rebased original with fixes for rerun of such reductions.
Manually tested workflow execution and everything seems fine. The workflow editor already thought this was possible, so that is another bug corrected by this enhancement.
To run the associated API test, execute the following command:
./run_tests.sh -with_framework_test_tools -api test/api/test_tools.py:ToolsTestCase.test_reduce_multiple_lists_on_multi_data
Conflicts:
static/maps/mvc/dataset/dataset-choice.js.map
static/maps/mvc/form/form-select-content.js.map
static/scripts/mvc/form/form-select-content.js
Modified this for the workflow export representation but this needed to be updated for the workflow editor because they shared some code in the manager. This was going to be needed downstream when I add labels and uuids to workflow outputs anyway.
Copy CWL style of specifying a outputs specification block at the top-level of the workflow specification and within that use the "source" attribute to specify the output. Reuse the specification used by "$link"s to describe this output - namely <label_or_order_index>[#<output_name=output>].
In downstream work this is used for subworkflows and nested tools. Not sure which of these would potentially hit main line Galaxy first so setting this all up in its own commit.
Lots of other tests would fail if simple uploads aren't working, but it is better to be direct and very explicit about why this particular test is failing.
Properly order the installation of the repositories adding
prior_installation_required="True". Otherwise filter_1440 is installed first
and ends in INSTALLED status because of the logic of
Repository.create_tool_dependency_with_initialized_env_sh_file() method
contained in
lib/tool_shed/galaxy_install/tool_dependencies/recipe/tag_handler.py .
This strategy proved to work around certain race conditions in tool testing so hopefully it will solve the transiently failing job searching and filtering test cases.
Martin Cech