Spreadsheet download - fixed columns

I noticed that on the search results page, the “spreadsheet” link yields a
fixed, hard-coded set of columns - not necessarily the columns that are
displayed on the page. This seems (to me) counter-intuitive - I would
expect to get a spreadsheet copy of what’s on the screen. The fact that the
whole of the query (& format) string is passes to Results.tsv seems to
indicate that the spreadsheet columns should match the screen columns.

Anyway, my question is - what is the intent of the link? And if it does
behave as intended, would there be interest in a second download link that
gives a spreadsheet copy of the displayed search results? I have a .tsv
that does this that I could contribute.

[One thing I found in digging around this subject, is that Results.html &
Results.tsv use different mechanisms for retrieving data - and that the
Results.html data retrieval piece has html code embedded. It would be good
if all of the search-processing pieces could use a common data-retrieval
component that would be independent of presentation method. The
Results.html data retrieval seems to be the most flexible, and is what I
used to do my own .tsv page - but this would involve removing html
knowledge from the data retrieval]

Steve

Stephen Turner
Senior Programmer/Analyst - Client Support Services
Information Services and Technology (IS&T)

sturner@mit.edu

Steve,

So, the originial intent of the "Spreadsheet" link was to allow

administrative staff to download a ticket listing for reporting
purposes. As such, it was supposed to contain all columns, including
all custom fields. (This was a specific customer requirement for the
sponsor of the work) I wouldn’t object to having an additional link to
download only the columns displayed in the displayed format if people
would find it useful.

[One thing I found in digging around this subject, is that Results.html &
Results.tsv use different mechanisms for retrieving data - and that the
Results.html data retrieval piece has html code embedded. It would be good
if all of the search-processing pieces could use a common data-retrieval
component that would be independent of presentation method. The
Results.html data retrieval seems to be the most flexible, and is what I
used to do my own .tsv page - but this would involve removing html
knowledge from the data retrieval]

The current Results.html page uses newer infrastructure than
Results.tsv, though that’s largely because it was felt that they did
different enough things. The page that really wants a do-over using
the new infrastructure is the Bulk update page.

Best,
Jesse Vincent
Best Practical