4 22 2024 Tech Team Report

4-22-2024

Date	Task	Hours (Main)
15-Apr-2024	Continue debugging social reg redirect, quick report by slack	2
16-Apr-2024	Report, investigate failing setResponse calls/add a new flag/mechanism to handle redirect after Terms dialog.	4
17-Apr-2024	Coord re: deactivate warnings, coord re: stage update with HEAL, investigate/work-around Keycloak bug with profiles, prestage blocks, schema changes on stage, prod, process stage ldap file	2
18-Apr-2024	Update stage Keycloak, Drupal, Dataverse, ldap changes, solr schema changes, new mdblocks, remove old DOI/mail settings, investigate possible duplicate names on prod, difference in user counts between Ldap, Drupal, and Dataverse on stage and prod, coord re updates.	7
19-Apr-2024	Coord re: Mesh workshop, work to shift DataCite provider to use exported datacite xml	3

Deploy all updates from dev to stage - DV6.2, new SSO, Drupal maintenance updates and associated changes
Investigated accounts on stage and prod where collisions with our default username would occur (name from @ when the same name is used with more than one email domain) as well as cases where ldap/keycloak accounts exist w/o Drupal accounts and vice versa.

Finished fix for social registration not redirecting to Dataverse and therefore also not passively logging-in the new user at Dataverse
Investigate / work around Keycloak bug (the recent updates to keycloak caused it to fail whenever you try to look at user's accounts. This is due to a problem in upgrading the experimental (as of 23.x) user profile feature. A workaround of trying to edit the json for user profiles and saving it, seemed to clear the issue on both dev and stage. (Will check on prod when we do the next update to 23.0.7)

Verify that can't deactivate Dataverse account warnings on dev were on old accounts/due to failures to create DV accounts in earlier tests (and confirmed that the warning (seen only by admins deleting a user in Drupal) is just that - not a problem unless the DV account is known to exist in which case it would indicate some real error.

Start adapting DataCite export to use OpenAire-style of parsing and to merge QDR changes in the DataCite export into the merged version.

(From last week) Any reason to keep old branches? (They take space on the Jenkins machine). Unless someone can think of a reason, I'll go ahead and delete anything that's been merged. Most of them are for PRs to IQSS since I've been making most QDR changes directly on the develop branch.
Any old accounts (e.g. ones with collisions) to delete from prod before the SSO update? Any preferred mechanism for resolving the collisions (nominally for most I've added '2' at the end of the older account but this pattern (or deleting) doesn't always work, e.g. there are three different info@ addresses that are truly different accounts and not cases where a person has changed institutions (and presumably won't be using their old account).

Work on MFA w.r.t. on authentication issue #43(MFA, etc.)
Work on metadata issue #44 (more metadata to DataCite, etc.)
Fix Stata-14 ingest by allowing file inspection during direct upload or adjusting the Stata ingester.
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
- Make PR for guestbook adding datasetversion fix
- Popup info accessibility - IQSS likes the recommendations from the source I linked to, so this can be implemented along those lines.
QDAS Previewer
- Updates per request
- Investigate writing aux file/previewing lower-sensitivity version and/or other write options
TBD: FRDR Security