Re: [389-users] Server Side Sort, Virtual List View and Aci

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luca, Hi Andrey,

Could you open a bug on the bugzilla under 389?  We'd like to 
investigate it.

Thanks,
--noriko

Andrey Ivanov wrote:
> 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<lucam@xxxxxxxxxx>:
>> 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
>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
> --
> 389 users mailing list
> 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users


[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux