[FEATURE] control ordering of tabs in UI spreadsheet generation

[mshadbolt]

When generating spreadsheets from the UI the tabs and columns are organised in a somewhat random order whereas ideally we would like to order them in a way that makes the most sense to the user.

Firstly I'd like to figure out the best way to order tabs, columns and modules.

Then I need to figure out how that might be possible either in the way the UI asks the generator for the spreadsheet, or in the the generator itself.

Acceptance criteria:

• [x] defined ordering of tabs decided defined ordering of columns/modules decided
• [ ] changes made to implement the ordering in the ui/generator
  • [ ] function to order the tabs written
  • [ ] function called within convert function
  • [ ] automated tests written to test above functionality

[mshadbolt]

There is wrangler consensus that the ordering of tabs should follow the ordering of experimental linking, e.g. from a simple primary tissue experiment should be:

donor organism, collection protocol , specimen from organism , dissociation protocol , enrichment protocol , cell suspension, library preparation protocol, sequencing protocol, sequence file.

[mshadbolt]

Discussion about the ordering of the columns didn't reach a resolution. I think I will drop this from this ticket and focus on the tab ordering.

I investigated the generator code and the generator generates a spreadsheet with the tabs in the order that is specified by the SpreadsheetSpec(). Therefore I believe it would make sense to add a function to the ui code that orders the tabs in the order we want before it returns the spec to generate the spreadsheet. I believe the best place for this would be to add the function call within the convert function

The logic to order the tabs should follow the experimental graph. That is:

• biomaterial with no links first
• followed by the biomaterial that contains the first biomaterial as a link
• but with the protocol link(s) to the linked biomaterial sandwiched between.

I am not 100% on whether this logic will always work so we should come up with some good test cases once implemented.