Code de-dup in workflow controller.
Refactor helper out for detailed encoding of a workflow for API.
Move building workflows from dictionaries into new WorkflowContentsManager.
Going to build up a WorkflowContentsManager that is reponsible for slightly more complex operations involving step logic, etc... and keep the WorkflowsManager focused on CRUD-like and sharing operations.
Refactor updating workflow contents out of mixin into manager.
Introduce an API endpoint for this operation with test case.
Move body of _workflow_to_dict to new WorkflowContentsManager.
Getting closer to killing UsesStoredWorkflowMixin.
Move more workflow logic out of controller into manager.
This logic for building up editor representation of the workflow.

Introduce concept of a workflow to dict style - with 'export' and 'editor' as first cracks.
Introduce yet another workflow to_dict style - 'instance'.
This is the style used by workflow 'show' - this consolidates all step handling to_dict style-logic from controller/base.py, controller/workflow.py, and api/workflows.py into the new WorkflowContentsManager - with API test cases for everything.
Allow implicit connections between workflow steps (no editor GUI yet).
This means steps that are not connecting an output of one step to the input of another. This could potentially address all sorts of untraditional (in a Galaxy sense) workflows where some sort of data is managed externally. The most important use I think I have heard discussed is that of data managers - this can be used in cases where data managers depend on one another (grab the fasta files in one step, index them in another) or workflows where a downstream analysis depends on index data populated via data managers in earlier steps.

Not really sure how to represent these in the workflow editor - but this is a power user feature anyway so hopefully that is not super pressing. The YAML to workflow DSL supports the operation (see test cases) so these power users (a euphemism for Dan I guess) can just use that for now.
Slightly improved error message for incorrect workflow connection uploads.
De-duplication of step creation across update and create worklfows.
De-duplicatation for setting up workflow connections during creation/update.
Create abstraction for walking over step dicts to share between create/update methods.
Augment workflow step model for improved tracking.
Give every step a UUID that can be preserved across edit to the workflow. Likewise - allow every step to be given a label (a unique short name for that workflow) - that allows for a human consumable way to reference steps for use in tests and when driving workflows via the API. Workflow editor doesn't yet (and might never) display these attributes but it does preserve them across workflow saves.

Implement automated testing that uploading workflows, updating workflows, and exporting them handle UUID and labels. Manually tested workflow editor preserves labels and UUID across changes.
Pack scripts (for workflow step tracking changes).
Ensure unique step label and UUIDs across workflows during create/update.
Allow specifing workflow parameter replacements by step UUID.
Allow specifing workflow inputs by step UUID.
Pass in the parameter 'inputs_by' as 'step_uuid' to the workflow run command to use this.

Specifing inputs by UUID has the nice advantage that it survives workflows saves - so if one sets up an API script or something to target a workflow - saving the workflow in the editor doesn't need to break the script as long as inputs were not added or deleted. The UUID (like the order_index) has the advantage of the step id that it is predeterminable - so one can set it up a workflow script against any Galaxy and the script doesn't need to be adapted to raw ids the steps get assigned in that instance.
Allow workflow inputs to be specifiable by UUID without explicit inputs_by.
Since there is no chance of conflict with step.id or step.order_index, just allow inputs or ds_map respectively to be indexed by UUID.