job_directory -> jobs_directory
Thanks Trevor!

Merged in trevorw/galaxy-central-5/trevorw/job_directory-jobs_directory-1397077266550 (pull request #360)

job_directory -> jobs_directory
Charts: Add label selection columns
Display repository dependency definition attributes for repositories being installed into Galaxy where the dependency hierarchy cannot be determined likely due to invalid dependency definitions.
Include tool version information in bug reports.
When posting to BioStar include a ToolShed url, as applicable.
merge next-stable
Change suc.get_url_from_tool_shed to common_util.get_tool_shed_url_from_tool_shed_registry.
Corrected version for migrated tools.
Merge with next-stable.
Remove unused variable?
Refactor interaction between workflows JS and editor JS for adding nodes.
Add abstraction into editor for use by galaxy.workflow.js to hide some editor details from workflow code and reduce duplication between add_node_for_tool and add_node_for_module.
Outline workflow editor tests.
Simplify enable_output_terminal and enable_output_terminal in workflow editor.
These functions were taking in a single element and then looping through it. I hope this is not some intententional jQuery pattern to change the value of 'this' I don't quite understand and is just a remnant of when some loop over inputs was on the inside of this function or some other such refactoring.
Record history content type with output of history contents API.

Downstream in dataset collections branch this isn't just dataset, including this will allow clients to distinguish between different kinds of content.
Refactor backbone models to allow different kinds of history contents.

In particular, add a new backbone parent model (HistoryContent) refactored out of HistoryDatasetAssociation. This makes room for a forth coming HistoryDatasetCollectionAssociation model that will be emitted from the history contents API.

There are likely better ways to share common functionality between a dataset and a dataset collection contents - more JS savy developers should feel free to refactor into smaller mixins for instance. For now HistoryContent is just composed of the overlap in functionality between dataset and collection representations downstream and is an quick and dirty way to share said functionality.
Refactor backbone views to allow different kinds of history contents.

This makes room for a forth coming HistoryDatasetCollectionAssociation model that will be emitted from the history contents API. Same comment as previous changeset applies - this is a potentially crude way to share duplicated functionality and a better design would be most welcome.
Rename historyPanel.refershHdas to refreshContents.
Add simple module verions of validation stuff in base controller.

For reuse outside of controllers (i.e. in dataset collections). Objections to refactoring base controller stuff to use this?
Extract base class from DataToolParameter to be shared with DataCollectionToolParameter.