Views And Other Directory Features - Netscape DIRECTORY SERVER 6.1 - DEPLOYMENT Deployment Manual

Note that the
ou=Location Views, dc=example,dc=com
contain a filter. This feature facilitates hierarchical organization without the
requirement to restrict the entries contained in the view further. Any view may
omit the filter. Although the example filters are very simple, the filter used may be
of arbitrary complexity.
It may be desirable to limit the type of entry that the view is to contain. For
example, to limit this hierarchy to contain only people entries, simply add an
attribute to
nsfilter
value
(objectclass=organizationalperson)
Each view with a filter restricts the content of all descendent views while
descendent views with filters also restrict their ancestor's contents. For example,
creating the top view
mentioned above would create a view with all entries with the organizational
object class. When you add the descendent views that further restrict entries, and
the entries that now appear in the descendent views are removed from the ancestor
views. This demonstrates how virtual DIT views mimic the behavior of traditional
DITs.
Although virtual DIT views mimic the behavior of traditional DITs, views can do
something that traditional DITs cannot, that is, entries may appear in more than
one place. For example, if it were required that
and
Mountain View
that by simply adding the
would appear in both views.

Views and Other Directory Features

Both class of service and roles features of the Directory Server support views; see
"Grouping Directory Entries," on page 71. When adding a class of service or a role
under a view hierarchy, the entries that are both logically and actually contained in
the view are considered within scope; for information on using these features, refer
to Chapter 5 "Advanced Entry Management" in the Netscape Directory Server
Administrator's Guide. This means that roles and class of service can be applied
using a virtual DIT view, but the effects of that application can be seen even when
querying the flat namespace.
Access control with views must be performed slightly differently than is usual.
Because there is currently no explicit support for ACLs in views, it is recommended
that you create role-based ACIs at the view parent and add the roles to the
appropriate parts of the view hierarchy. In this way, you can take advantage of the
organizational property of the hierarchy.
ou=Location Views, dc=example,dc=com
ou=Location Views
(see Figure 4-3 on page 80), you can accomplish
Sunnyvale
value to the location attribute and the entry
Sunnyvale
Virtual Directory Information Tree Views
view entry itself does not
.
first along with the new filter
be associated with both
Entry B
Chapter 4 Designing the Directory Tree
with the filter
83