2010/8/25 Rich Megginson <rmeggins at redhat.com>
> Andrey Ivanov wrote:
>
>> Hi,
>>
>> I am testing the 389 latest git version. There is one thing i have
>> noticed concerning Outlook browsing of LDAP and VLV indexes. Though i
>> think the change has happened already some time ago, in one of the
>> previous versions.
>>
>>
> Can you confirm the last version that this worked in? I suspect this had
> something to do with my matching rule changes in 1.2.6. The goal is that it
> should work the same way as before, so this is definitely a bug.
No. It is not a bug, it was my mistake. I've just tested several versions
of 389 and FDS (1.2.x, 1.1.x and 1.0.4). They all exhibit the same behavior
concerning the sorting of CNs in VLV browsing.
So then i still have this second question - is there a way to change the vlv
index sort in order to sort according to nsMatchingRule? Or it would be a
feature request?
*) i've tried to add collation rules to vlv index entries but putting the
value of the attribute vlvSort to
"cn:2.16.840.1.113730.3.3.2.18.1.6" or to "cn:fr". It does not work.
Instead of changing the sorting order it produces some strange contents in
the index vlv#outlookbrowseindex.db4 file.
**) then i thought that maybe i should change the cn index ordering and i
have added "nsMatchingRule: 2.16.840.1.113730.3.3.2.18.1" to the cn indexes
in dse.ldif. However reindexing does not actually change the order in
cn.db4 (even after reindexing by smth explicit like db2index -n userRoot
-t cn:eq,pres,sub:2.16.840.1.113730.3.3.2.18.1 ) in the index .db4 files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100825/292546a7/attachment.html
