Skip to content
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

[BACK-2780] Add new user profiles endpoint. #698

Open
wants to merge 62 commits into
base: master
Choose a base branch
from

Conversation

lostlevels
Copy link
Contributor

@lostlevels lostlevels commented Feb 12, 2024

Since a lot of this is copy paste from shoreline, for reviewers:

  • shoreline/user/user.go => platform/user/full_user.go - (because there's already a type called User). platform/user.go user.User extended with shoreline user fields.
  • shoreline/user/hasher.go => platform/user/hasher.go
  • shoreline/user/storage.go => platform/user/user_accessor.go (somewhat like the interface of the Storage repository, but simplified).
  • shoreline/user/migrationStore.go => platform/user/keycloak/user_accessor.go (Takes the logic around User creation / manipulation and removes the fallback / mongodb stuff), implements platform/user.UserAccessor interface
  • shoreline/keycloak/client.go => platform/user/keycloak/client.go (Wrapper around gocloak).

@lostlevels lostlevels force-pushed the jimmy/BACK-2780-new-profiles-endpoint branch from 5abaa66 to 7d32881 Compare March 27, 2024 20:54
user/profile.go Outdated Show resolved Hide resolved
user/profile.go Outdated Show resolved Hide resolved
Copy link
Contributor

@toddkazakov toddkazakov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall it looks good. I found few issues:

  • There is a lot of cruft that was copied from shoreline. I believe the majority of those functions are not used. There's no reason to keep unused code in platform, because it only leads to confusion.
  • There is probably a gap in the requirements that I discovered when I read the seagull code to try and figure out why the profile endpoints require custodian permissions. In order to fully deprecate and migrate existing seagull profiles from Mongo to Keycloak, we have to provide an alternative implementation of this functionality. For each user sharing their data with a user with a given id seagull fetches the user object from shoreline and merges it with the user profile attributes stored in the profile object in mongo. The response is sanitized depending on the actual permissions of the requesting user. This deserves its own ticket, but please do some research what the linked code does and then write the requirements. The alternative implementation should be much simpler, because the user account and profiles will be stored in a single service (Keycloak).

auth/service/api/v1/profile.go Outdated Show resolved Hide resolved
auth/service/api/v1/profile.go Outdated Show resolved Hide resolved
permission/client/client.go Outdated Show resolved Hide resolved
permission/permission.go Outdated Show resolved Hide resolved
user/full_user.go Outdated Show resolved Hide resolved
user/full_user.go Outdated Show resolved Hide resolved
user/full_user.go Outdated Show resolved Hide resolved
user/hasher.go Outdated Show resolved Hide resolved
user/keycloak/user_accessor.go Outdated Show resolved Hide resolved
results := make([]*user.User, 0, len(mergedUserPerms))
// just doing sequentially fetching of users for now
for userID, trustPerms := range filteredUserPerms {
// Does this mean all users should already be migrated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we should migrate all users to mongo

return slices.Contains(TRUES, value)
}

func parseUsersQuery(query url.Values) *usersProfileFilter {
Copy link
Contributor

@toddkazakov toddkazakov Jul 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My impression is that this query is not used at all. Can we check blip and uploader?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On checking blip and uploader it seems they are indeed no query string parameters used.

blip
platform-client
uploader
uploader

Can you confirm that no query string parameters are passed for getAssociatedUsersDetails @krystophv @gniezen @jh-bate ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The blip and uploader calls are all piped through the platform-client function, so I believe you're correct - no query string params are being sent.

profile = profile.ClearPatientInfo()
} else {
if trustorPerms.HasAny(permission.Custodian, permission.Read, permission.Write) {
// TODO: need to read seagull.value.settings - confirm this is actually used
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Settings are not part of the profile object so probably there's no need to do anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the settings and preferences returned in the old seagull code, but don't know if they are actually used by clients. @krystophv @clintonium-119 @gniezen Do you know if the returned result of paltform-client getAssociatedUsersDetails ever uses the returned users' settings or preferences in blip or uploader?

// TODO: need to read seagull.value.settings - confirm this is actually used
}
if trustorPerms.Has(permission.Custodian) {
// TODO: need to read seagull.value.preferences - confirm this is actually used
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preferences are not part of the profile object so probably there's no need to do anything?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants