@mvdbeek and I discussed this in the Galaxy project gitter a few weeks ago and decided the propagation is too aggressive and should likely be done manually at the end of a workflow for now - using for instance the set tags collection operation tool.
- Selenium test case demonstrating their use in simple workflows.
- API test demonstrating they work with nested workflows from the run perspective.
- Update run variant of workflow to_dict to parse out replacement parameters to display on the backend and tweak the client to just accept these.
- Parse out replacement parameters for subworkflows recursively, include in new run output attribute - nested workflow replacement parameters work now.
- Selenium test case demosntrating subworkflow replacement parameters are rendered and used when submitted.
That should make the test less flakey. While in theory we should be able
to replace scheduled workflow jobs with cached jobs, this is not what
we're testing here, and I assume it doesn't work for now.
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.
Turns out integers are used as is in `random.seed()`, but strings are
hashed (in the version 1 protocol), and the hashing isn't stable. So
instead we hack around this by using `ord()` on each character and
concatenating the digits. Yucky, but probably better than using numpy
and putting this tool on the list of tools that inherit galaxy's
environment (or adding a requirement tag and resolving with conda ...).
mvdbeek