API backbone used to generate the progress bar for collections but applied to a workflow invocation. Should be helpful in quickly summarizing all the job states in a workflow invocation.
Implement markdown backend and frontend components as well generator plugin framework to allow customizable workflow invocation reports.
Architectural Choices on the Client
Old-style embedded objects vs components
In theory, this could make really nice use of excellent VueJS components for dataset display, dataset collection display, workflow display, etc.. These aren't available yet, we don't even really have Backbone stuff that exist very well outside history panels, so this re-uses "components" from Galaxy Pages for datasets and reuses the collection display for history panels as a stand-alone display for collections (I got this trick from DIsplayStructured.vue). This isn't ideal and I know that but at least reusing things this way will provide a path forward for migrating both pages and this new Markdown language (which could easily replace or co-exist with pages HTML someday) together seamlessly as the real modern components become available and doesn't increase the overall work needed to integrate newer style components. In fact, this might even be the impetus for creating and polishing more of these components.
markdown-it vs markdown-it-vue
I tried this with markdown-it-vue also but it added very little in terms of reducing client code, obscured entirely how to attach plugins to the markdown rendering process, and brought in many, many more extra packages that we don't need or want.
Given there is no representation of invocations in the GUI and not editor for reports config this is a bit challenging still. But here is goes:
- Source Galaxy's virtualenv.
- Login to a user and grab an API key, set in the following command:
- ``GALAXY_TEST_EXTERNAL=http://localhost:8080 GALAXY_TEST_USER_API_KEY=38175dfc69d9009992b69efcca8b209b pytest test/api/test_workflows.py::WorkflowsApiTestCase::test_workflow_invocation_report_custom``
- In the web browser go to http://localhost:8080/api/invocations and grab the latest invocation ID. Replace it in the follow query string.
- Navigate to http://localhost:8080/workflows/invocations/report?id=c887f1d0da42bdfe
Because multiple inheritance will result in calling this class 'delete' method
which is not the correct target. This also avoid a database operation
I believe, since the PurgableManagerMixin.purge also calls delete before purging.
This was an oversight in https://github.com/galaxyproject/galaxy/pull/7745.
This is the quick fix, but I think it's feasible to implement the
accessible logic as a query, which means we could push this down to
a Mixin, and treat it as a regular fiter (so admins could for instance
search/sort for the largest datasets, which is already possible in the
reports app).
In practice we use ParsedFiler.filter_type to discriminate
the different filter types. Filters that require the correct
model class for a specific query are now functions that take
a model_class and generate the correct filter.
Report if empty inputs were used or if the same input was used more than once, these were identified as common sources of potential errors across many tools. Neither of these are definite problems, but both could be depending on the tool and both happen frequently. Outline a few more ideas as TODOs in the code.
If the user is not an admin.
Fixes https://github.com/galaxyproject/galaxy/issues/7710
An alternative would be to skip Accessibility / Ownership
exceptions, but given that we can just restrict the query
this seems like the better approach to me.
mvdbeek