Prior to this, composite uploads were only allowed for select data types. As far as I can tell, the framework itself allows arbitrary datatypes to have extra files. This allows the upload API to take in extra files for datatypes that aren't explicitly annotated has having extra files.
These may be specified one at a time or in directory structures via tar files.
Fix warnings during py34-unit tests like:
```
/home/travis/build/galaxyproject/galaxy/test/unit/workflows/test_extract_summary.py:46: DeprecationWarning: Please use assertEqual instead.
self.assertEquals(job_dict[hda.job], [('out1', derived_hda_2)])
```
See e.g. https://travis-ci.org/galaxyproject/galaxy/jobs/438829277
There was an existing library dataset permission API and one proposed for HDAs in #6461. This tries to reconcile the two approaches and move toward managers.
- Proper treatment of "master_api_key" throughout the manager layers related to this.
- Use PUT instead of POST, since that is more appropriate for updates I believe.
- Use a similar URL pattern for library datasets, history contents, and dataset APIs.
- Generalize the dataset API to allow HDA or LDDA inputs (the proposal for the new API in #6461 added an HDA-only option to the dataset API - this isn't how that API layer is meant to be used I believe).
- Add an HDA only endpoint in the history contents API for this functionality to mirror the library dataset API.
- Use consistent and backward compatible payload parsing for these endpoints.
- Use consistent serialization for the result of these changes.
- Generalize the HDA variant of this to allow different actions - such as make public and make private that were available in the library dataset variant.
- Test cases for the new API endpoints, the roles API, tests for permissions during collection creation and running tools with both dataset and collection inputs.
- Switch select_tag to group_tag as a parameter name - since it is restricted to group_tags and we don't call data parameters select_data.
- Add minimal XSD documentation for this new parameter type.
- Add example tools - for single and multiple tags.
- Add API tests for these tools and the tag handling.
Unlike upload 1.0, use different 'src' types to distinguish between URLs and pasted content - in the abstract this is better because it is more structured and practically this allows 'pasting' spreadsheets that start with URLs for instance (that is sometimes useful).
It is jarring to users that works for collection inputs but not multiple data inputs, especially because the IUC discourages collection inputs when multiple data inputs would work.
It is jarring to users that works for collection inputs but not multiple data inputs, especially because the IUC discourages collection inputs when multiple data inputs would work.
Update tool XSD to encourage using fully qualified inputs.
Reorganized the existing tests for consistency with other test tools I think.
(Rebased with fixes, including XSD fixes from @nsoranzo.)
Allow the rules DSL & GUI component to operate on existing collections to allow filtering, sorting, modifying identifiers and general re-organization of existing collections (e.g. the outputs of tools). Implementing this as a collection operation tool so that it should be executable interactively in the tool form and in a batch fashion as part of workflow executions.
For this to be tracked properly as a tool execution and to work properly in the tool form, I've implemented a new tool framework and tool form parameter type called "rules".
This can thought of as a more GUI friendly alternative to my proposed collection operations that consumed JavaScript expressions.
This includes API tests for both tool and workflow execution of the new tool as well as Selenium tests for tool form execution, workflow editor interactions, and workflow running.
Should only affect unzip I think - fixes#5780 - probably need to rebuild collections though, collections built in the meantime are going to be broken in the DB.
Includes test case that fails against 18.01.
John Chilton