Category searching was effectively broken until the 1.2 betas, as we stored it as a single, comma delimited string (much like the file backend does) which rendered it unsearchable using an ldap query.
The "categories" attribute in the evolutionPerson schema has been deprecated in favor of the new "category" attribute, which is multivalued. So, in the old way you'd have something like: categories: Birthday,Competition and now: category: Birthday category: Competition which makes it possible to search using ldap. Chris On Mon, 2002-10-07 at 17:30, Greg Kerdemelidis wrote: > Hello all! We have an (Open)LDAP repository with our enterprise-wide > contact information stored in it. We did this from the ground up with > Evolution in mind as it handles editting the records. After converting > our contacts from Outlook 97 to LDIF and loading them into the > repository as evolution-person's, we cannot search using the Categories > field. > > I have enabled substring indexes, etc, on the LDAP back-end, and rebuilt > said indexes. Performing a query using ldap-search produces the required > results. As it pans out, this was a pointless step... > > After enabling the LDAP debugging, I looked at the traffic between > evolution and the db. It appears that evolution does its own matching on > the records it has retrieved (which is a piddly 100), rather than > querying the db. > > So, to make a short story long, why can't we get the Categories to work > with LDAP? > > Has anyone out there managed to sort out categories with LDAP? I'm one > step short of rearranging the repository into smaller OU's, one for each > category. This seems like a stupid idea, given that Evolution should > handle it. > > -Greg > > > > _______________________________________________ > evolution maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
