Hi! I am using idn.countIdentitiesBySearchableIdentityAttribute method on an identity attribute rule, which was working fine until today. I invoke it like
but for some users, it is returning 0, even if there does exist some user with “someUID” (that is, it should return 1). I notice that it happens when the existing identity belongs to another identity profile/source.
Is this the expected behaviour, that is, it counts identities that match attribute == value on the identity profile where the rule is used?
If so, can anyone tell me if idn.findIdentitiesBySearchableIdentityAttribute works in the same way, or can I use it as a workaround?
Based on your note about “multiple identity profiles”, my guess is that there’s another identity profile of higher priority that makes this identity profile return “0” because it’s not the “master” for the identity. You should be able to confirm the identity profile source by looking at the identity detail page to confirm.
This is strange, I have not faced this issue and I haven’t seen any document or info that Identity Profile has significance here. I need to get identities irrespective of Identity Profiles.
BTW are you trying to implement some uniqueness logic ?
Hi Krishna, yes rule is doing some uniqueness check, against uid attribute (although it is not recommended, this case uses random numbers). It works fine, but I found a case in which count returned 0, and there was an identity with the same uid. Only thing I can figure it is that count only works for identities inside the identity profile where it is defined, because existing uid identity was created many time ago, but with another identity profile, resulting in 2 identities with the same uid.
Looks like you are not getting unique employee ID from your HR system. So you need to generate. We used employee ID from HR systems so didn’t face this issue.
But this doesn’t make any sense to me, end of the day it is identity and should have unique uid else it will mess up the system rite.
In this case we can not use other fields, because there is a corporate login algorithm predefined. First in IDN, and later on other applications. Strange is that it let the duplicated login co exist, there were 2 identities with the same uid. Only the warning at the identity profile page, instead of not allowing to create and send to identity with errors page.