Otherwise, if re-running fails once, then re-running it again successfully
will let the other workflow jobs resume, but the collection element is not
replaced and the collection remains red.
- Require a URL or FTP column for raw pasted data.
- Require list identifiers if creating collections.
- Require name in more scenerios that require a name.
A mistake was made in the rush to rule-builder-all-the-stuffs - libraries, hdas, and FTP all initialized a different set of columns from the data (which is probably fine) but with no indication this was happening in the underlying rules (which is definitely not fine).
To understand why this was a mistake and see why in the long term this hurts reproducibility, take loading rules for HDAs from the history panel as an example. In the initial implementation it would pre-initialize two columns - one for "hid" and one for "name" - any rules that were generated from there would start with an implicit assumption of two columns. This is a problem because if someone saves some rules and we (Galaxy developers) decide later on that name tag should be in the initial list but HID doesn't make sense and make that change - we basically are breaking all existing rules to support a very logical change in behavior. Likewise, Galaxy produces a hash with last modified date and size for each FTP entry - this is data we have and could stick in the rule builder by default - but if we change that over time existing FTP rules will break.
It would be much more sustainable to instead include the initial column generation information in the initial rules generated - so that each of these modalities start in reality with an empty table and the initial set of rules describe what metadata to pull initial columns from. This way if you save a set of rules it will include the initial column choices, and if they are pasted in at some later point where columns are picked differently - the rules will still work because you are replacing the initial column definitions.
The initial rules implementation didn't have this concept of loading columns from metadata - but this was added to support loading existing identifiers as part of the "Apply Rules to Existing Collection" tool. This commit extends that idea to do the same thing (but with different columns) when loading data from HDAs, FTP, and data libraries.
Dannon Baker