UNSAccountBHasUNSItemB

Hello,

You may want to investigate Account Definitions and how to put those to use.  See https://support.oneidentity.com/technical-documents/identity-manager/8.0.2/administration-guide-for-connecting-to-custom-target-systems/17#TOPIC-1017828 for more.

But I assume you mean assigned items to the Employee, correct?

Trevor

In general, yes. We deactivate an Employee, his or her UNSAccountB through account definition is disabled and all assigned ItemsB to this UNSAccountB are deactivated. And if we re-activate the employee his or her UNSAccountB through account definition is enabled and all assigned items to this UNSAccountB are reactivated.

OK, so I'm not sure what you're asking for, or what the issue is?

You'll never change XIsInEffect directly that's why it is read-only. The flag will be used by the system (DB Queue Processer etc.).

Well, in reality it doesn't happen. Items are not deactivated by some reasons. I wonder why and how we can change it.

Which version are you using? Are the UNSItemsB directly assigned or via UNSGroupB assignments?

8.0.1 and directly assigned.

The account definitions do not handle the removal of directly assigned UNSAccountBHasUNSItemB entries OOTB. If the UNSItemB entries are assigned via UNSGroupB items, the removal of the group memberships would remove the UNSItemB memberships as well.

The only solution I can see currently - without changing the way you are assigning the data is to do the following:

Attention

This is for experienced users only. If you are uncomfortable with changing or creating SQL procedures please refrain from doing so.

If you still do, have a fresh backup at hand and test this thoroughly in your dev. environment before implementing this into your production environment.

You could take the procedure TSB_ZUNSAccountBHasUNSItemB and create a custom version of it CCC_ZUNSAccountBHasUNSItemB.

By duplicating the algorithm from TSB_ZUNSAccountBInUNSGroupB that uses dbo.TSB_FGIUserInGroupValid to check the flags implement your wanted custom behavior for UNSAccountBHasUNSItemB.

The new procedure CCC_ZUNSAccountBHasUNSItemB needs to be put into QBMDBQueueTask instead of TSB_ZUNSAccountBHasUNSItemB as ProcedureName.

Be aware that this change is not safe for migration. Means, after migrating the database you need to re-apply the changes in QBMDBQueueTask. We do have an open enhancement request that would make such changes in QBMDBQueueTask untouched during the migration but this is not implemented yet.

The account definitions do not handle the removal of directly assigned UNSAccountBHasUNSItemB entries OOTB. If the UNSItemB entries are assigned via UNSGroupB items, the removal of the group memberships would remove the UNSItemB memberships as well.

The only solution I can see currently - without changing the way you are assigning the data is to do the following:

Attention

This is for experienced users only. If you are uncomfortable with changing or creating SQL procedures please refrain from doing so.

If you still do, have a fresh backup at hand and test this thoroughly in your dev. environment before implementing this into your production environment.

You could take the procedure TSB_ZUNSAccountBHasUNSItemB and create a custom version of it CCC_ZUNSAccountBHasUNSItemB.

By duplicating the algorithm from TSB_ZUNSAccountBInUNSGroupB that uses dbo.TSB_FGIUserInGroupValid to check the flags implement your wanted custom behavior for UNSAccountBHasUNSItemB.

The new procedure CCC_ZUNSAccountBHasUNSItemB needs to be put into QBMDBQueueTask instead of TSB_ZUNSAccountBHasUNSItemB as ProcedureName.

Be aware that this change is not safe for migration. Means, after migrating the database you need to re-apply the changes in QBMDBQueueTask. We do have an open enhancement request that would make such changes in QBMDBQueueTask untouched during the migration but this is not implemented yet.

Yes, thank you.