DT-1662: Ensure single Library Card per User #2536

rushtong · 2025-05-22T22:29:35Z

Addresses

https://broadworkbench.atlassian.net/browse/DT-1662

Summary

This PR enforces that a user can only have a single library card. There are a significant number of test changes to support this requirement. For backwards compatibility with the UI, we're populating the User object with a libraryCard and a list of libraryCards. When the UI is updated to match this, we can come back and remove the deprecated field.

Notes

There will need to be a follow-on PR in the UI to deal with the user model describing an array of library cards. See https://github.com/DataBiosphere/duos-ui/blob/ee9e70640759c33bed9e6b9f8b5393f4692dea8b/src/types/model.ts#L51 for where we need to start there.

See these tickets for that work:

There are deletes for duplicate user_id and user_email rows. In Prod, there are no records affected. In Dev and Staging, there are 2 and 1 record respectively that will be removed.

Testing

Tested the db update with a recent db download from

✅ Dev
✅ Staging
✅ Prod

Tested the UI Admin/SO Library Card table functionality

✅ Dev
✅ Staging
✅ Prod

Have you read CONTRIBUTING.md lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

rushtong · 2025-05-23T13:29:49Z

src/main/java/org/broadinstitute/consent/http/db/UserDAO.java

-      + " LEFT JOIN roles r ON r.role_id = ur.role_id "
-      + " WHERE LOWER(u.email) = LOWER(:email) "
-      + " AND r.role_id = :roleId")
-  User findUserByEmailAndRoleId(@Bind("email") String email, @Bind("roleId") Integer roleId);


Only used in tests

rushtong · 2025-05-23T13:33:09Z

src/main/java/org/broadinstitute/consent/http/db/mapper/UserWithRolesReducer.java

+  // Some queries look for `user_role_id` while those that use a prefix look for `u_user_role_id`
+  private UserRole mapUserRoleFromRowView(RowView rowView, Integer userId) {


In theory, I don't think this method should be necessary. However, I found that the mapping wasn't working for cases where the prefix was ur_ and couldn't get that to work like I think it should.

rushtong · 2025-05-23T13:37:46Z

src/main/java/org/broadinstitute/consent/http/resources/DaaResource.java

-      User user = userService.findUserByEmail(authUser.getEmail());
-      List<LibraryCard> libraryCards = libraryCardService.findLibraryCardsByUserId(userId);


This is a bug. When we remove DAAs from a library card, we need to remove them from the user passed into the method via userId. This code will remove a DAA from the AuthUser's library card.

Good catch!

Should this method also be checking that the SO is from the same institution as the user?

This is currently not enabled in any environment so I want to tackle any explicit functional changes to DAA work as a distinct task. We will need to re-evaluate the entire feature before we do any further work here.

Made a ticket to remind ourselves: https://broadworkbench.atlassian.net/browse/DT-1704

# Conflicts: # src/test/java/org/broadinstitute/consent/http/db/LibraryCardDAOTest.java

Copilot

Pull Request Overview

This PR enforces that a user may have only a single library card by replacing all references to collections of library cards with a single library card field. Key changes include updating test cases to use setLibraryCard instead of setLibraryCards, modifying service methods in UserService and DataAccessRequestService to check for a single library card, and adjusting the DAO/mappers and associated YAML schema for consistency.

Reviewed Changes

Copilot reviewed 21 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/test/java/org/broadinstitute/consent/http/service/DataAccessRequestServiceTest.java	Updated tests to replace empty libraryCards checks with a null check on libraryCard
src/test/java/org/broadinstitute/consent/http/resources/DataAccessRequestResourceTest.java	Modified tests to use setLibraryCard in place of setLibraryCards
src/main/resources/assets/schemas/User.yaml	Deprecated the collections field and added the libraryCard field
src/main/java/org/broadinstitute/consent/http/service/UserService.java	Adjusted user creation and retrieval to assign and output a single library card for backwards compatibility
(Other files)	Consistent update from list-based library cards to a single library card across DAOs, mappers, and resource classes

Files not reviewed (2)

src/main/resources/changelog-master.xml: Language not supported
src/main/resources/changesets/changelog-consent-2025-23-unique-lc-user.xml: Language not supported

sonarqubecloud · 2025-05-23T20:40:11Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

fboulnois

Looks good, a suggestion:

fboulnois · 2025-05-27T17:20:29Z

src/main/java/org/broadinstitute/consent/http/db/UserDAO.java

+          ld.daa_id as lc_daa_id
+      FROM users u
+      LEFT JOIN user_role ur ON ur.user_id = u.user_id
+      LEFT JOIN roles r ON r.role_id = ur.role_id


Should we pull this common section into something separate referenced by this method and the other one?

@fboulnois if we do that, won't we get complaints from SemGrep? Or are you suggesting we also change that configuration at this time?

If I had to guess, it's why this class is being refactored in this way.

If I had to guess, it's why this class is being refactored in this way.

This is the primary reason why this is refactored, yes. The string concatenation approach has been problematic to maintain and triggers semgrep issues. I would like to see if we can come up with a better way of re-using large query blocks in some other way, but for now, this is the least bad option as I see it.

fboulnois · 2025-05-27T17:26:01Z

src/test/java/org/broadinstitute/consent/http/db/UserDAOTest.java

@@ -191,7 +207,7 @@ void testFindUsersWithLCsAndInstitution() {

    User user2 = createUserWithInstitution();
    int lcId2 = libraryCardDAO.insertLibraryCard(user2.getUserId(),
-        user.getDisplayName(), user.getEmail(), user.getUserId(), new Date());
+        user2.getDisplayName(), user2.getEmail(), user2.getUserId(), new Date());


Good catch.

otchet-broad · 2025-05-27T21:09:10Z

src/main/java/org/broadinstitute/consent/http/db/mapper/UserWithRolesReducer.java

@@ -56,34 +48,56 @@ public void accumulate(Map<Integer, User> map, RowView rowView) {
        }
      }
    } catch (MappingException e) {
-      //Ignore institution mapping errors, possible for new users to not have an institution
+      logDebug("Error adding Institution to User: %s".formatted(e.getMessage()));


Thanks for adding the case of the debug logs. I find them helpful for local development.

otchet-broad · 2025-05-27T21:39:37Z

src/main/java/org/broadinstitute/consent/http/resources/DaaResource.java

@rushtong - Do I understand correctly that everyone can read every DAA?

@otchet-broad - yes, all DAAs are intentionally public.

otchet-broad · 2025-05-27T21:43:17Z

src/test/java/org/broadinstitute/consent/http/db/LibraryCardDAOTest.java

+          ((PSQLException) e.getCause()).getSQLState());
+    }
+    User user2 = createUser();
+    // Test Unique on library_card.user_email - note that we're using the same email as user1


otchet-broad · 2025-05-27T21:59:09Z

src/main/java/org/broadinstitute/consent/http/models/User.java

@@ -101,7 +101,7 @@ public User(String json) {
    // Nor do we need to retrieve the full institution object from user-provided data.
    JsonObject filteredUserJsonObject = filterFields(
        userJsonObject,
-        Arrays.asList("createDate", "institution", "libraryCards"));
+        Arrays.asList("createDate", "institution", "libraryCard"));


Do we also have to support libraryCards until they're completely deprecated?

I don't think we do. This method constructs a User object. Since User doesn't have a libraryCards field so if a user-provided string does contain libraryCards, it will be ignored on the next line in gson.fromJson()

rushtong added 17 commits May 22, 2025 18:28

wip: first pass at making LCs singular - compilation and most tests pass

74865a0

revert

fd1b491

unused import

b4a7a3a

reduce log level

5a5009d

formatting

ad471eb

test fix

ffa0e2c

test fix

18b1dac

test fix

cbf0a45

test fix

c3dce93

test fix

0d3a35e

enforce in db

e62bc4e

swagger model update

31b496f

populate both for temporary compatibility

e1b102c

fix test for unique violation

0dbb51e

new tests for updated user queries

5271514

retain comment for helper method

5490d01

rm query only used in test

098ee34

rushtong commented May 23, 2025

View reviewed changes

rushtong marked this pull request as ready for review May 23, 2025 13:43

rushtong requested a review from a team as a code owner May 23, 2025 13:43

rushtong requested review from fboulnois and rjohanek and removed request for a team May 23, 2025 13:43

rushtong added 5 commits May 23, 2025 10:42

delete duplicates

c1f2a61

fixx test bug

0cecb3b

test updates for unique constraints

e8f293b

Merge branch 'develop' into gr-DT-1662-single-lc-per-user

0dcf0e5

# Conflicts: # src/test/java/org/broadinstitute/consent/http/db/LibraryCardDAOTest.java

test cleanup

e0a9ba5

method rename; rm duplicate test

a03a0f9

rushtong removed request for fboulnois and rjohanek May 23, 2025 15:49

restrict duplicate email rows to null user ids

89c17c5

rushtong requested review from Copilot, fboulnois and otchet-broad May 23, 2025 17:15

This comment was marked as resolved.

Sign in to view

rushtong added 3 commits May 23, 2025 13:55

further restrict duplicate user id deletes to non-null user id rows

beacde0

copilot feedback

6ae6055

copilot feedback - update test for clarity

a6f4815

rushtong requested a review from Copilot May 23, 2025 19:13

Copilot AI reviewed May 23, 2025

View reviewed changes

Merge branch 'develop' into gr-DT-1662-single-lc-per-user

d6cfedc

fboulnois approved these changes May 27, 2025

View reviewed changes

otchet-broad reviewed May 27, 2025

View reviewed changes

otchet-broad approved these changes May 28, 2025

View reviewed changes

rushtong merged commit 37ff736 into develop May 28, 2025
16 checks passed

rushtong deleted the gr-DT-1662-single-lc-per-user branch May 28, 2025 13:45

rushtong mentioned this pull request May 29, 2025

DT-1695: Use the singular LC object on user DataBiosphere/duos-ui#2888

Merged

		// Some queries look for `user_role_id` while those that use a prefix look for `u_user_role_id`
		private UserRole mapUserRoleFromRowView(RowView rowView, Integer userId) {

		User user = userService.findUserByEmail(authUser.getEmail());
		List<LibraryCard> libraryCards = libraryCardService.findLibraryCardsByUserId(userId);

DT-1662: Ensure single Library Card per User #2536

DT-1662: Ensure single Library Card per User #2536

Uh oh!

Conversation

rushtong commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Addresses

Summary

Notes

Testing

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rushtong May 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

sonarqubecloud bot commented May 23, 2025

Quality Gate passed

Uh oh!

fboulnois left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rushtong commented May 22, 2025 •

edited

Loading

rushtong May 23, 2025 •

edited

Loading