If an entry is deleted, the references to it are deleted or modified to reflect the change. When this update is applied to all entries and all groups, it can impact performance and prevents flexibility of restricting the referential integrity to selected subtrees. Defining a scope addresses this problem.
For example, there may be one suffix,
dc=example,dc=com, containing two subtrees:
ou=active users,dc=example,dc=com and
ou=deleted users,dc=example,dc=com. Entries in
deleted users should not be handled for purposes of referential integrity.
The following three attributes can be used to define the scope in the Referential Integrity Postoperation plug-in configuration.
This multi-value attribute controls the scope of the entry that is deleted or renamed. It defines the subtree in which the Referential Integrity Postoperation plug-in looks for the delete or rename operations of a user entry. If a user is deleted or renamed that does not exist under the defined subtree, the plug-in ignores the operation. The attribute allows you to specify to which branches of the database the plug-in should apply the operation.
This attribute also controls the scope of the entry that is deleted or renamed. It defines the subtree in which the Referential Integrity Postoperation plug-in ignores any operations for deleting or renaming a user.
This attribute controls the scope of groups in which references are updated. After a user is deleted, the Referential Integrity Postoperation plug-in looks for the groups to which the user belongs and updates them accordingly. This attribute specifies which branch the plug-in searches for the groups to which the user belongs. The Referential Integrity Postoperation plug-in only updates groups that are under the specified container branch, and leaves all other groups not updated.