Skip to content

9 25 2023 Tech Team Report

Jump to bottom
qqmyers edited this page Sep 25, 2023 · 1 revision

9-25-2023

Logged Tasks

                            Date             Task Hours (Main) Hours (EOLS) Hours (PII) Hours (QDAS)
18-Sep-2023 Reporting, change reg form wording per request, adjust tab sequence in Keycloak login dialog 2
19-Sep-2023 Respond to GBAR review requests - fix UI selection mechanism 2
20-Sep-2023 Additional fix to UI selection mechanism, investigate/start fixing GBAR download counting, explore how to estimate downloads at scale, revert table split from #5863; deploy D8 core sec fix to dev/stage, meeting 6
21-Sep-2023 Update GB queries, investigate/develop/debug new estimation query for large instances, deploy, test, make db update idempotent 3
22-Sep-2023 Update GBAR PR, add notes, investigate issue w/ terms dialog when launching preview, find/investigate old bug w.r.t. showing terms dialog for tools on file page. 5

Operations

SSO

  • Made changes to the registration form text per request
  • Adjusted the tab sequence in the Keycloak login dialog so that tab stops for social logins mirror where they are in the dialog

Drupal

  • Updated the core with a security fix, deployed to dev/stage

Dataverse

  • Continued responding to review requests for the GB-at-request PR.
    • Fixed UI selection mechanism to set GB at request or at download per collection.
    • Addressed problem of counting access requests as downloads. Existing code assumes 1 gb response == 1 download. To handle this for both direct counting and with the postgres stats-based estimation for large instances, I decided to undo the separation of the guestbook and filedownload tables done by ADA in prep for the GB-at-request functionality, added a new AccessRequest event type for guestbook responses, and then adjusted all queries to count downloads as gb responses that aren't of AccessRequest type. I also investigated postgres' stats (used by the query planner) and found a way to get the fraction of gb responses that aren't AccessRequests to be able to adjust the estimated number of gb responses to get estimated downloads. I tested the various cases where the table is/isn't big enough to estimate and to handle when there are too few AccessRequests for that stat to exist, etc. Once done, I updated the flyway script to change the estimate and made the update idempotent.
    • Also adjusted the Metrics API queries to account for access request responses.
  • In testing the GB-at-request functionality, I discovered that the dialog prior to viewing a preview showed GB fields and had no accept button. In investigating that, I ran across some broken code from when previews were first added to the file page that I needed to understand/fix to be able to fix the new issue I found.

AnnoRep

Discussion

  • As of today, I think the GB-at-request functionality is back to being ready for QA. Unless review of the latest fix shows new issues, this should be done. The latest updates are in the PR and on dev and stage.

Plans

  • SSO
    • Test ORCID member API use with the new member sandbox credentials
    • Clean out old corrupt test datasets - required before v5.14 can be deployed to prod.
    • Support testing as needed
  • Fix #113 if possible
  • Matomo - investigate event-level tracking via tag manager, remove non-working google scripts
  • AnnoRep - explore round-trip, configure auto-start and log rotation
  • Ops
    • check missing globalidcreationdates and fix via /modifyRegistration or alternative
  • Dataverse
    • Track ADA guestbook branch and merge when working, Make PR for guestbook adding datasetversion fix, deploy to stage
    • Popup info accessibility - IQSS likes the recommendations from the source I linked to, so this can be implemented along those lines.
  • Drupal - v10 - review compatibility and start updates.
  • QDAS Previewer
    • Updates per request
    • Investigate writing aux file/previewing lower-sensitivity version and/or other write options
  • TBD: FRDR Security
Clone this wiki locally