ProjectMembership created with invalid user refere...
# support
h
Hi, I'm trying to follow the guide for token exchange and am having some issues. As I was troubleshooting, I came to the aha moment -- I had no set an external id on the User or ProjectMembership. So I go to check my user resource, however my instance seemingly has no users despite them being referenced by the project membership. This is where I am stumped. - All project members were invited using the "invite new user" button in app.medplum.com , so I expect all necessary resources are created - When I look at a ProjectMembership, I do see all the expected memberships, and I can see references to users uuids - However, when i try to edit that membership in the UI, there is no user set so I cannot save any changes. (see attached screenshot) - My /fhir/R4/User/ returns no results - https://app.medplum.com/User shows no users I tried inviting a new user but have the same issue. To try and hack my way around this, I also try to create a user resource directly in app.medplum.com but get a 403 returned. Reading through the docs and the code @ server/src/admin/invite.ts , I'm not seeing anything obvious. Any ideas?
r
HI @hnoj. , thanks for the thoughtful question. So one important clarification: - The User is a protected, system-level resource. This means that it won't be visible in the Medplum App. However, if you go to the JSON tab, you should see that the User property is set - I believe that this fact is causing a bad interaction with our UI, causing that field to appear blank
It seems like this is a bug in our referential integrity logic. Because the User resource is hidden, the validation check on
ProjectMembership.user
fails https://github.com/medplum/medplum/issues/3203
I've filed a GH issue above
Unfortunately, the workaround for now would be to disable "Check references on write", edit the external id, and then re-enavle
@hnoj. I'd also love to understand your use case a bit more. Most of our customers don't opt into the reference checks, and I'd love to understand more about the requirements of your application
h
@rahul1 it looks like the same issue blocks your suggested workaround. I cannot edit the project to disable
checkReferencesOnWrite
because
owner
is an invalid reference I tried doing this through the Edit tab as well as the JSON tab. I've also tried doing each while enabling superAdmin -- hoping that would allow me to resolve the owner reference -- but alas no luck. Is there another way to disable checkReferencesOnWrite? The only option that comes to mind at this point is to spin up a new project 😬
Happy to discuss in depth more, but the TLDR of use case was - We are evaluating medplum, and started with translating a set of our data to fhir and syncing it to medplum. We wanted some guarantee of correctness to avoid "garbage in, garbage out" - From our POV (w a nascent understanding of fhir best practives), A reference like
Practicioner/123
being unresolvable on the server indicates a failure somewhere for us. We are only dealing with our own in house practitioners, etc. right now so they should all be resolvable within the FHIR store. - In the majority of other API's we use, we'd expect a reference to a non-existant resource like that to fail. So enabling that feature aligns medplum better with our current mental model Is it the right long term choice? I'm unclear but having it does feel like a nice safety blanket, while removing it made us think we'd need extra defensive coding on our end (which is still prone to races, etc.)
r
Yes I do believe this is the right long-term choice, and I'm sorry about the rough edges you are encountering thusfar. I'll try to get an update on that ticket and report back to you
In the short term, I'd love to unblock you. I can use my own SuperAdmin priveledges to disable
checkReferencesOnWrite
for your project, just so you can continue you're evaluation. I'll also notify ou when the issue has be resolved so we can re-enable it. Would that work for you?
h
I saw https://github.com/medplum/medplum/pull/3207 was merged (and deployed? Idk how to check that, but it seems to have been deployed) and I can edit these fields in the UI now 👍 So I don't think I need your manual intervention now, but I really appreciate the offer! Big thanks to you & the team, its been impressive to see how fast y'all are at making these changes 🎉
r
Oh wow! I've been in meetings and the team fixed it while i wasn't looking. Awesome!
Thank you @cody
122 Views