-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add groupsFor(AuthenticatedUser au) method #3055 #3062
Conversation
if (identifierWithoutAtSign != null) { | ||
roleAssigneeSvc.getUserGroups(identifierWithoutAtSign).stream().forEach((groupAlias) -> { | ||
ExplicitGroup explicitGroup = explicitGroupProvider.get(groupAlias); | ||
if (explicitGroup != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the full lambda experience, you can use map
to map the group alias to an explicit group, filter
out the null
s, and then use a collector to get the set of groups.
@scolapasta I'm passing this pull request to you to decide whether to merge it or not since @kcondon has already tested the code and closed the issue it fixes (#3055). |
Hmm, this pull request has merge conflicts now in src/main/java/edu/harvard/iq/dataverse/RoleAssigneeServiceBean.java It looks like getUserGroups was renamed to getUserExplicitGroups in 56f14ee I made this simply change but testAssignGroupAtDataverse isn't passing:
Not sure what's going on here or what the priority of #3055 is. |
Tested pre merge code with @pdurbin , saw similar issue, so seems unrelated to merge. |
I just replicated the problem Gustavo saw. I switched to 3055-get-more-groups, didn't attempt to merge, and the test fails:
I'm not sure what's going on but I'll spend an hour or so trying to figure it out. |
I just dropped my database with |
Conflicts: src/main/java/edu/harvard/iq/dataverse/RoleAssigneeServiceBean.java Here are the changes I had to make: - Make RoleAssigneeServiceBean.getUserExplicitGroups public. - Stop using old getUserGroups name. Also, SearchIT better reflects reality in terms of which tests can run successfully at this time.
These are the conflicts I saw when merging "develop" (7fe7040) into "3055-get-more-groups" (ea89841):
Here are the changes I had to make (see 3cc98db):
On a clean, new database the test passed:
Last week I showed @scolapasta how to hack SearchIT.java into running just the test I wanted to run (testAssignGroupAtDataverse) but this was ridiculous. In 3cc98db I added a todo at the top to indicate that the SearchIT tests are not working and added a bunch of |
@scolapasta as described in my last comment at #3062 (comment) I merged "develop" into this pull request and got the "testAssignGroupAtDataverse" test we were looking to pass but this required me dropping my database. Why? I think there's something odd going on with mismatched user IDs, as I originally reported at #2418. To get the test to fail again, (to make my database unclean?) all I have to do run the "AdminIT.java" tests which converts users from builtin to shib and back again. Then "testAssignGroupAtDataverse" from SearchIT.java fails and "testUserId" from BuiltinUsersIT.java fails as well. Here's the javadoc i wrote there:
@scolapasta I'm passing this to you to see what you think. |
@scolapasta it turns out the mismatched user ID problem was simply me not understanding which ID I was getting back in the JSON response when creating a builtin user. In pull request #3124 I'm suggesting that we should return both the builtin user id and the authenticated user id (and more). If you'd like I could merge the branch for that pull request into the branch for this one and then clean up SearchIT.java to get the ID from the authenticated user or the builtin user. This way the test will always pass, regardless of if you have Shib users in your database or not. |
RFI Checklist
1. Related Issues
2. Pull Request Checklist
3. Review Checklist
After the pull request has been submitted, fill out this section.