Andrey Ivanov wrote: > > > 2010/8/25 Rich Megginson <rmeggins@xxxxxxxxxx > <mailto:rmeggins@xxxxxxxxxx>> > > 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. I did see some code in the vlv code to handle i18n matching rules, and there is indexing code for i18n matching rules. Not sure what's going on here - haven't had a chance to look into it. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
