check for nulls in provisioning translation scripts in a sensible way

Chris Hyzer
29 minutes ago
Regarding the azure provisioning discussion...
a subject becomes unresolvable, so AADC deletes the user from Azure, which removes them from their groups. But Grouper wants to be the thing that removes the user from groups, and gets REALLY HUNG UP on trying to delete non-existent users from Azure groups that it's managing
This wasnt the provisioner not deleting a user who doesnt exist, it was a translation issue. I think we need to get used to checking for nulls in translation scripts, which is not easy in jexl... e.g. from
${grouperProvisioningEntity.subjectIdentifier2 + '@whatever.onmicrosoft.com'}
to
${grouperProvisioningEntity ? (grouperProvisioningEntity.subjectIdentifier2 ? (grouperProvisioningEntity.subjectIdentifier2 + '@whatever.onmicrosoft.com') : null) : null}
We should see what happens if subjectIdentifier2 is required, maybe the framework will not try and fail to translate. Also since this is the search identifier, currently it needs to be cached for deletes. Again, we can improve that in the future.
Anyways, in short, I think this is not a problem currently...
:+1:
1
:ty-thank-you:
1

New

Carey Black
23 minutes ago
checking for nulls in translation scripts, which is not easy in jexl...
Maybe each Jexl expression could/should have a list of evals that need to be "not null" that could be config'ed .
Maybe the nesting structure could be auto constructed dynamically from the list of vars to increase readability of the config and not require an independent Jexl eval operation?

Chris Hyzer
< 1 minute ago
I think the list of configs not null makes sense...