[ENG-6283] User table allows CSV and TSV downloads

[Johnetordoff]

Purpose

Allows CSV and TSVs be downloaded from the user tab on the institutional dashboard page by adding a format query param. Such as in v2/institutions/cos/metrics/users/?format=csvor v2/institutions/cos/metrics/users/?format=tsv or v2/institutions/cos/metrics/users/?format=json_file

Changes

• adds CSV/TSV renderer to view
• add .extra(size= to ensure spread sheets cover whole report, not one page.
• adds Json renderer to metrics reporter
• adds tests

QA Notes

Please make verification statements inspired by your code and what your code touches.

• Verify
• Verify

What are the areas of risk?

Any concerns/considerations/questions that development raised?

Documentation

Side Effects

Ticket

https://openscience.atlassian.net/browse/ENG-6283

[aaxelb]

looks good, yay for code reuse!

my only request would be to add a Content-Disposition header that gives the downloaded file a sensical filename

[Johnetordoff]

Maybe change format param to fix collision with normal json format?

[Johnetordoff]

@aaxelb There was an issue where the pagination was limiting the files to 10 items, the default page size, so I had to address that between reviews, just heads up if you are wondering about the diff.

[aaxelb]

would be good to keep a logical separation of concerns -- a renderer should work with the data it's given; this is logic that belongs in the view

(tho might be even better to skip the special casing and let the client set page[size]=10000)

[aaxelb]

i don't think we need yet another json renderer; we only need a way to download the existing json as a file (instead of opening in the browser)

how about accepting a forDownload query param in ElasticsearchListView (or even JSONAPIBaseView?) that toggles a Content-Disposition header? could work the same way for any format, reducing special-casing

[Johnetordoff]

In considering this I think the user probably doesn't want meta and general pagination information that would come from this endpoint. It should be a pure list, like the tabular formats are. But still considering options here.

[aaxelb]

is that based on user feedback? (not sure where "it should be a pure list" came from, when talking about a non-tabular format like json)

total counts and pagination information seem like helpful info to include (especially if they can choose a page size, or if there are more than 10000), and easy to ignore if they don't need it

[aaxelb]

(could understand wanting to omit relationships, but i'd argue the effort would be better spent making ElasticsearchListView support sparse fieldsets (so the download could reflect selected columns from the frontend, implicitly omitting relationships))

[aaxelb]

this is getting beyond the scope of the ticket, but it'd be nice for RecentReportList to inherit ElasticsearchListView, now that it exists (instead of only duck-typing get_default_search) -- could be fuller-featured and more consistent, but might also rabbit-hole, so don't bother unless you want to