Michael Karrer wrote:
For classic cos, apart from its natural filtering for cos class and schema checking (you know cos checks schema before supplying attributes right?), you could make the cos depend on roles by using the nsrole attribute to determine class - this is called role based attributes. Then you can determine the cos by any method available to roles, including ldap filters.Hello List, is there a way to limit (filter) the target entries of a CoS?
(We are planing to integrate a Adress Book with companies and Sub companies but the Cos should only be active for one level and not down to the bottom)There is currently no innate ability to limit the depth of scope for either cos or roles. However, here's a trick you could employ to limit roles to one level which when combined with role based attributes should get you what you need. Determine the filter you require for your dynamic role, request the entryid attribute from the parent of the target entries, then modify the filter like so:
(&(parentid=<the entryid from above>)(<your original filter>))Note that this is not infallible, entryids are unique only within the backend instance so if there happens to be another entry in another backend that has children and the same entryid, then those children would be effected too.
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
