When multiple contacts with the same user ID are assigned to different access types, the Set Role dropdown may be missing.
Article ID: 7744
Updated On:
Products
Issue/Introduction
It is possible to de-install the force_unique_userid option which is included as a Security option of Options Manager.
After the option has been de-installed, it is possible to create multiple contacts with the same User ID.
For example, in one use case, two contacts with the same User ID could be assigned with different Access Types and different Tenants. For example, both contacts have the same User ID, one contact may have the tenant set to a super tenant and one contact may have tenant set to the sub tenant; both contacts have a different Access Types - one of those access types has only 1 role; the other access type has multiple roles.
Note: Assigning different tenants requires the multi_tenancy option to be installed.
With the setup as described in the above use case, the resulting behavior may be problematic. One symptom may be that the Set Role dropdown is not available after the contact logs into the web interface.
Environment
Cause
There are known documented side-effects of de-installing the force_unique_userid option.
The description of the option includes warnings, as shown in the duplicated information below:
force_unique_userid
Prevents using duplicate active system login names. Especially when LDAP import is performed, there are many issues seen that duplicate user ids got created. So it is always recommended to have this option enabled.
Important! We recommend that you keep the force_unique_userid option enabled at all times. If this option is uninstalled, and there are multiple contact records with the same login id, you may experience problems with data partitions, multi-tenancy, security, and other functionality.
Resolution
A work-around is suggested below. The work-around is not guaranteed; it is a suggestion which seemed to help for the particular use case but it has not been thoroughly tested so other side-effects of operations could be discovered. Please seriously consider the "Important!" note below.
In the mentioned use case, the work-around is to ensure that the access types being used across the contacts include more than one role.
So, for example, if the access type for one contact is the Employee Access Type, which has only one role, which is the Employee role, then you could add a second role to the Employee access type. The second role could be a separate copy of the existing Employee role.
Consider that adding a role to an access type affects all contacts that are assigned to that access type.
Important! Please re-consider your business case for de-installing the force_unique_userid option. Keep the option Installed to avoid many other problems for which work-arounds may not be possible and for which a product fix would be highly improbable.
Additional Information
Some warnings in the documentation about de-installing the option can be found on the following pages (hint: search for "force_unique_userid" within the pages):
Feedback
