clarification about filtering for dynamically added attrs (ITS#7486)

diff --git a/doc/man/man5/slapo-dynlist.5 b/doc/man/man5/slapo-dynlist.5
index f9185cff23587e3a2e07c2332655bc3ce35a14e5..830bb79078ecbdd22d9037cf3df72f9c1712f65c 100644 (file)
--- a/doc/man/man5/slapo-dynlist.5
+++ b/doc/man/man5/slapo-dynlist.5
@@ -12,16 +12,23 @@ The
 overlay to
 .BR slapd (8)
 allows expansion of dynamic groups and more.
-Any time an entry with a specific objectClass is being returned,
-the LDAP URI-valued occurrences of a specific attribute are
+Any time an entry with a specific objectClass (defined in the overlay configuration) is being returned,
+the LDAP URI-valued occurrences of a specific attribute (also defined in the overlay configuration) are
 expanded into the corresponding entries, and the values
 of the attributes listed in the URI are added to the original
 entry.
 No recursion is allowed, to avoid potential infinite loops.
+
+Since the resulting entry is dynamically constructed,
+it does not exist until it is constructed while being returned.
+As a consequence, dynamically added attributes do not participate
+in the filter matching phase of the search request handling.
+In other words, \fIfiltering for dynamically added attributes always fails\fP.
+
 The resulting entry must comply with the LDAP data model, so constraints
 are enforced.
 For example, if a \fISINGLE\-VALUE\fP attribute is listed,
-only the first value results in the final entry.
+only the first value found during the list expansion appears in the final entry.
 The above described behavior is disabled when the \fImanageDSAit\fP
 control (RFC 3296) is used.
 In that case, the contents of the dynamic group entry is returned;