Hello Alshahim. The AttributeMetaData is the likely cause here. That entry still shows user="user name", which means the manager value was originally set through the identity creation form. Since the mapping was later changed to a Global Rule, the old metadata may still be preventing the new mapping from replacing or clearing that value. This is a known behavior when switching between direct mappings and rules.
As a test, remove just the <AttributeMetaData attribute="manager" .../> entry from one affected identity through Debug, then run an Identity Refresh with “Refresh identity attributes” selected. If that works, a controlled BeanShell task would be the way to handle it across multiple identities rather than editing them one by one.
Also confirm that the Global Rule is the only applicable mapping for manager. When the rule returns null, IIQ continues evaluating any remaining source mappings, so a later mapping could still provide a manager value.
Since manager is an Identity-type attribute, I would not return an empty string to clear it. Clear the stale metadata first and test the existing null return in a lower environment. Once the metadata is corrected and no later mapping supplies a value, the Global Rule should be able to clear the manager during identity refresh.
Hello @punna0001 ,
Thanks for this valuable answer ,
in another attribute wich is also identity-type attribute and initialy provisionned by the form, the value is updated by the global comparing to the manager attribute,
Or maybe this behavior is specific to the manager attribute ?
Thankx
The manager attribute is a built-in system attribute on the Identity object, rather than a custom extended Identity-type attribute, so I would not necessarily expect both attributes to behave identically during refresh.
That said, the other attribute working does not rule out the metadata issue, because AttributeMetaData is maintained separately for each attribute.
Could you compare the metadata entries on the same identity after a refresh?
If the working attribute shows the Global Rule as its source but manager still shows user="user name", then the stale manager metadata is still the likely cause.
If both show the Global Rule as their source, the issue is more likely specific to the manager mapping or the value returned by the rule.
In the second case, I would add a temporary log statement to confirm that the rule executes for the affected identity and returns a real null when the manager should be cleared. Also confirm that no other source mapping is configured below the Global Rule for manager, since IIQ evaluates the configured mappings in order until one supplies a value.
“Refresh manager status” updates whether an identity is considered a manager of other identities. The option that recalculates the mapped manager attribute is “Refresh identity attributes.”
Hi @alshahim04 Based on the details you provided, you just need to run the Identity refresh with the Attribute sync and refresh manager check boxes selected. This will clean the manager and even the metadata. Try this option, I hope it works.