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.
Test various configuration options (ftp_upload_dir, ftp_upload_identifier, ftp_upload_dir_template) and various upload API parameters (space_to_tab, to_posix_lines, auto_decompress).
- Allow running through ``run_tests.sh``.
- Enable more verbose test errors for Conda tests.
- Refactor how integration tests depend on API testing (use a Mixin instead of subclassing conceptually conflicting TestCase classes).
Add tests for new date range and history filtering as well as to ensure only admins get to see external_id and command_line and that users cannot see each other's jobs.
Always allow admins to views all jobs on index (instead of only when user_details is specified) and show. Add user_email and external_id to show (for admins) to bring it inline with index and add command_line to index (for admins) to bring it in line with show.
Show still allow more details including job standard error and output as well as job metrics.
Previous run_as method has some potential limitations, seems testing permission/security things is more correct if actually using normal alternative user key.
... if you can call 1 new class a framework. Includes a few test cases to exercise/drive it. These examples include a histories API test (a typical API test) and a general test of the API framework itself (mostly just the run_as functionality).
This includes changes to interactor.py to make it more useful outside the context of tool/workflow testing as well as a tweak to test Galaxy that gets started to allow testing of the run_as feature.
Nicola Soranzo