2010/8/25 Rich Megginson rmeggins@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.