09 14 2020 Tech Team Report - QualitativeDataRepository/TechnicalTeam GitHub Wiki

9-14-2020

Date	Task	Hours (Main)	Hours (EOLS)
8-Sep-2020	Report, meeting	1
9-Sep-2020	Add per-file download metrics, add graph, minor csv/display fixes, update PRs, update stage, restart prod with mail debug, investigate jar difference	6
10-Sep-2020	Update stage to Drupal 8.9.5, update prod with Drupal, Dataverse, metrics app, cleanup/configure metrics app - shuffle graphs, add panels, add start date, truncate 0 total portion of graphs (#46), update metrics PR	7
11-Sep-2020	Debug/update adopting orig file metadata in replace, add clickable datasets/files to metrics graphs, update webforms for Drupal8	2	2

Metrics:

Added per-file metrics (API additions and new graphs) and stopped including months with 0 total counts in timeseries requests
Changed the layout of the graphs page (order of graphs, added 3 panels that can be hidden for downloads, MDC, and holdings information, added configurable titles/messages that can be used, for example, to note MDC start date(s))
Made all dataset and file graphs that show per-item information have clickable links to bring up the relevant pages in Dataverse
Updated Dataverse and dataverse-metrics PRs

Drupal

Dataverse

Debugged/fixed displaying/storing the metadata (name, path, tags, provenance, not mimetype or md5 hash) of the original file when doing a file replace via the UI (in v5.0).

Operations:

Restarted prod to turn on mail debug logging and discovered that the war file built for prod included a different aws-java-sdk-bundle-1.11.172.jar file than other builds. Replacing that file fixed the problem with sending mail from prod.

Work through any v5.0 issues
Update #4380 to stop a replacement file from having the same name as another file (per IQSS feedback)
Look into file DOI reservation

Still TBD:

I don't understand how/why the v4.20-qdr-7 build on prod ended up with a bad jar file. The files had the same name/version, the pom.xml manifest hadn't changed. Other than some temporary problem at some maven repository that allowed download of a bad file, I can't think of how this could have happened. Would be useful to discuss this and whether further action to detect/prevent similar problems is worthwhile.
File replacement - review/discussion with Gustavo at IQSS pointed out a flaw in my design for #4380 (see above) and led to the recognition that, with file DOI reservation, replacing a file in draft is different from replace of a previously published file in that the latter assigns a new DOI to the old version (since it is still available) whereas replacing a draft would presumably involve adopting the reserved DOI. (Files are different that dataset versions in this sense since there is only on DOI per dataset, not per-version. The proposal is just to name the operation differently for the draft-only case.