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 1a8b4f07bf94377d2131db174fa4488650e6dfab..fe544d5ff0782e2a8952546d1ead6a559a084ff1 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;