$set-accounts propagation and deprecated strictMod...
# support
j
I'm in the process of setting up a multi-tenant project, and when I use $set-accounts with the propagate flag set to
true
, I get a bunch of validation errors. Looking through the source code, $set-accounts strictly validates the resources it is propagating the account information to. I haven't been running the project in
strictMode
, so normal resource CRUD work bypasses validation. But looking at the strictMode setting on projects I see this message:
Whether this project uses strict FHIR validation. This setting has been deprecated, and can only be set by a super admin.
Why is $set-accounts doing validation on my project that does not have
strictMode
enabled? Is
strictMode
truly deprecated? If so, is it deprecated in favor of another validation mechanism?
a
Hey @Jim Fiorato! Your project's
strictMode: false
setting only affects writes made through your user context. For
$set-accounts
all of its writes go through the system repo, which always has
strictMode
hardcoded to true. This means that resources in your project which were written while
strictMode
was off may not pass validation with
$set-accounts
, resulting in the validation errors you're seeing. You’ll need to identify and fix the failing resources before running
$set-accounts
with
propagate: true
. You can use the
$validate
to find which resources will fail without actually writing them. We recommend always using
strictMode: true
.
j
Ok, great. Thanks for the info. Wonder if I missed that recommendation in the docs. If not, might make sense to make more prominent, since the recommended setting is off by default, and the wording in the documentation suggests that strictMode is deprecated.
r
@Jim Fiorato - it may make sense to do a check up on your cluster, as strictMode is on by default. It is possible you are running an old version, or have disabled strictMode by default, but it is highly recommended.
j
Thanks Reshma. We were able to fix all the data up and enable it. We created the project back in 4.0.4, so maybe wasn't the default then? Anyway, all good now.
32 Views