"GAF" download button on search annotation pages no longer works

[kltm]

There seems to be two issues with the GAF download button on /seach/annotations.

1. after clicking and clicking on "Download", nothing happens
2. do we really want the "?" there as the symbol--that's weird

As reported by @elserj.

[kltm]

For "1" there, it reports as

TypeError: results_table is undefined

in bbop.widget.display.button_templates.field_download .
I'm guessing a change in the button API at some point has caught up with us.

[kltm]

This may all be mooted by #104 if things work on that side of the fence.

[kltm]

Nope, not mooted, but a slightly more heartening error:

TypeError: results_table.get_selected_items is not a function

[kltm]

The selection error only occurs with the annotation downloads. I'm guessing this is due to annotation IDs being stored like:

"MGI\tMGI:1917253\t1700028I16Rik\t\tGO:0005575\tMGI:MGI:2156816|GO_REF:0000015\tND\t\tC\tRIKEN cDNA 1700028I16 gene\t\tprotein\ttaxon:10090\t20120430\tMGI\t\t\t",

but called like:

%28%22MGI%09MGI:1917253%091700028I16Rik%09%09GO:0005575%09MGI:MGI:2156816|GO_REF:0000015%09ND%09%09C%09RIKEN%20cDNA%201700028I16%20gene%09%09protein%09taxon:10090%0920120430%09MGI%09%09%09%22%29

Is it storing as tabs, or as literal \t? I'm pretty sure it has something to do with a mismatch in there.

[kltm]

Both of these work in the ontology_class download, so unlikely to be something with the parens or quotes:

http://localhost:8080/solr/select?defType=edismax&qt=standard&wt=csv&rows=10000&start=0&fl=id&csv.encapsulator=&csv.separator=%09&csv.header=false&csv.mv.separator=|&fq=document_category:%22ontology_class%22&q=id:GO:0003674

http://localhost:8080/solr/select?defType=edismax&qt=standard&wt=csv&rows=10000&start=0&fl=id&csv.encapsulator=&csv.separator=%09&csv.header=false&csv.mv.separator=|&fq=document_category:%22ontology_class%22&q=id:%28%22GO:0045999%22%29

[kltm]

Well, using luke, the solr index itself has it as tabs, with:

<id:MGI MGI:1922735 1700010B08Rik       GO:0005575  MGI:MGI:2156816|GO_REF:0000015  ND      C   RIKEN cDNA 1700010B08 gene      protein taxon:10090 20100202    MGI         >

So maybe there is a way to figure out how to get these IDs to match (http request into Solr and document id in Solr), but this is such a nasty way to generate IDs I feel like we should just give up here and generate less nasty IDs for annotation documents from the get-go.

@hdietze, do you have any opinion here? While having the IDs "mean" something has been nice, I think I'm good without this in particular (encoding tabs? ugh). Either hashing, UUID, or incremental. Given that we do this in the nasty loader and we already have no self-respect there, another nice unique ID could be:

<time hash (a la noctua)> + <input gaf name> + <input line number>

Simple unique ID, that could still give some interesting info if things went south.

[kltm]

Have finally gotten around to testing. After a refresh of the index (with more sensible IDs), it is working again as expected.