Fedora directory users - Aug 2006 - CoS Problem - any way to limit (filter) the Target entrys

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)


Thanks for any Help!

Michael Karrer wrote:
> 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)
I suppose you could create a Filtered Role, where the search filter 
matches only those entries you want to match.  Then, create a CoS where 
the cosSpecifier is the DN of your Filtered Role
definition.
>
>
> Thanks for any Help!
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Michael Karrer wrote:
> Hello List,
>
> is there a way to limit (filter) the target entries of a CoS?
>
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.
> (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

Pete Rowley wrote:
>
> 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.
I should have said "if there happens to be another entry in another 
backend /that is a descendent of the parent and/"

-- 
Pete