Hi Luca, I have the same problem - i have two OUs and an ACI that "hides" one of these OUs to anonymous users. When i implement a VLV index level higher than these two OUs and use Outlook to browse the directory everything is rather scrambled because if the VLV indexes. So the problem really is the joint use of ACIs "hiding" some of the entries and VLV indexes. Don't know whether it can be considered as a bug or as a feature request but this is what we need desperately before deploying it large scale (primarily Outlook clients using this VLV)...
@+ 2011/3/14 Luca Menegus <[email protected]>: > Hi, > when searching ds using ServerSideSearch control and VirtualListView control > it does not seem to take into account the configured ACIs when returning the > contentCount field of the VirtualListView response control. > The contentCount field of the VLV response control it will be set to the > total number of entries matching the search and not to the number of entries > matching the search AND searcheable by the user performing the search. > > Example: > - there are 10 people in the directory, 5 in peopleA ou and 5 in people B ou > - userA can search (and read) the anything under peopleA > - userB can search (and read) the anything under peopleB > - SuperUser can search (and read) the anything > > If I bind and search as SuperUser everything works as expected (contentCount > is 10) and I can "scroll" through the rs as expected. > If I bind and search as UserA contentCount is still 10 and the resultset > contains "holes". For instance if sort the search so that entries under > peopleB come first then requesting (using VLV control fiels) 5 entries from > entry #1 returns an empty rs, while requesting 5 entries from entry #5 > returns the expected 5 entry under peopleA. > > The behavior when searching as userB is consistent (the other 5 entries are > returned). > > I'm using 389-ds-base-1.2.7.5-1.fc14.x86_64 under fc14-x86_64. > > I'm I doing something wrong, or is this the expected behavior? > > > Luca > -- > 389 users mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
