Search List mixes fields

With the current CVS code, the search list mixes the fields.

Fri, 11 Apr 2008 14:57:05 +0000

With the current CVS code, the search list mixes the fields. That happens to all fields that are in the view. But only if its a sql source and the name field is composed by firstname and lastname. The name field is in the list view shown as "lastname lastname", but in the details of a contact the name field is shown correctly. More strange is the in the list view fax column shows now the email address and the fax number disappeard. But in the contact details page they are correctly shown. This happens not for a ldap resource without a composed name field. This behavior occured after one of the last updates. More strange: Seaching in imp in the addressbooks for the same resources that have the problem with the list view, no addresses are found any more. Only for ldap or a sql resource that has no composed field it is still finding addresse. Thanks for this great flexible application Holger

Sounds like a consequence of Jan's recent changes.

Fri, 11 Apr 2008 15:34:56 +0000

Sounds like a consequence of Jan's recent changes.

Unless I'm mis-understanding the issue, I cannot reproduce t

Fri, 11 Apr 2008 15:56:37 +0000

Unless I'm mis-understanding the issue, I cannot reproduce this. Can you give a bit more detail? (The way 'name' is configured in sources.php, and the actual values in the various name fields maybe?) Thanks!

Here is the config of that source: 'map' => array(

Sat, 12 Apr 2008 13:23:18 +0000

Here is the config of that source: 'map' => array( '__key' => 'id', '__uid' => 'id', 'name' => array('fields' => array('firstname', 'lastname'), 'format' => '%s %s'), 'firstname' => 'first_name', 'lastname' => 'last_name', 'title' => 'title', 'department' => 'department', 'birthday' => 'birthdate', 'homePhone' => 'phone_home', 'cellPhone' => 'phone_mobile', 'workPhone' => 'phone_work', 'otherPhone' => 'phone_other', 'fax' => 'phone_fax', 'email' => 'email1', 'emails' => 'email2', 'assistant' => 'assistant', 'homeStreet' => 'primary_address_street', 'homeCity' => 'primary_address_city', 'homeProvince' => 'primary_address_state', 'homePostalCode' => 'primary_address_postalcode', 'homeCountry' => 'primary_address_country', 'workStreet' => 'alt_address_street', 'workCity' => 'alt_address_city', 'workProvince' => 'alt_address_state', 'workPostalCode' => 'alt_address_postalcode', 'workCountry' => 'alt_address_country' ), 'search' => array( 'name', 'email', 'homeCity', 'homePhone', 'workPhone', 'cellPhone' ), 'strict' => array( 'id', ), 'tabs' => array( 'Allgemein' => array('firstname', 'lastname', 'birthday', 'title', 'homePhone', 'cellPhone', 'workPhone', 'fax', 'email', 'emails'), 'Addressen' => array('department', 'assistant', 'homeStreet', 'homePostalCode', 'homeCity', 'homeProvince', 'homeCountry', 'workStreet', 'workPostalCode', 'workCity', 'workProvince', 'workCountry') ), 'export' => true, 'browse' => true, 'use_shares' => false, ); In the browser I see following in the surch list following field of the details page Name: Wegner, Wegner Firstname: Wegner Lastname: Wegner Phone privat: the cell phone number cell phone: the business number Phone business: the privat number Fax: the email addess E-Mail: nothing city privat: the postalcode its completly mixed. In the debug log I see following for a search: Apr 12 15:22:25 HORDE [debug] [horde] Connected to the following memcache servers:localhost:11211 [pid 25755 on line 123 of "/usr/share/php/Horde/Memcache.php"] Apr 12 15:22:25 HORDE [debug] [horde] Read session data (id = 82635f3ca4552932271d46828f2f2946) [pid 25755 on line 164 of "/usr/share/php/Horde/SessionHandler/memcache.php"] Apr 12 15:22:25 HORDE [debug] [turba] Hook _horde_hook_share_init in application horde not called. [pid 25755 on line 1595 of "/usr/share/php/Horde.php"] Apr 12 15:22:25 HORDE [debug] [turba] SQL query by Turba_Driver_sql::_search(): SELECT id, first_name, last_name, title, department, birthdate, phone_home, phone_mobile, phone_work, phone_other, phone_fax, email1, email2, assistant, primary_address_street, primary_address_city, primary_address_state, primary_address_postalcode, primary_address_country, alt_address_street, alt_address_city, alt_address_state, alt_address_postalcode, alt_address_country FROM contacts WHERE (((LOWER(first_name) LIKE LOWER(?) OR LOWER(first_name) LIKE LOWER(?)) AND (LOWER(last_name) LIKE LOWER(?) OR LOWER(last_name) LIKE LOWER(?)))) [pid 25755 on line 166 of "/opt/horde/turba/lib/Driver/sql.php"] Apr 12 15:22:25 HORDE [debug] [turba] SQL query by Horde_Alarm_sql::_list(): SELECT alarm_id, alarm_uid, alarm_start, alarm_end, alarm_methods, alarm_params, alarm_title, alarm_text, alarm_snooze, alarm_internal FROM horde_alarms WHERE alarm_dismissed = 0 AND ((alarm_snooze IS NULL AND alarm_start <= ?) OR alarm_snooze <= ?) AND (alarm_end IS NULL OR alarm_end >= ?) AND (alarm_uid = ? OR alarm_uid = ?) ORDER BY alarm_start, alarm_end [pid 25755 on line 148 of "/usr/share/php/Horde/Alarm/sql.php"] Apr 12 15:22:25 HORDE [debug] [turba] SQL query by Turba_Driver_sql::_search(): SELECT object_id, object_type, owner_id, object_firstname, object_lastname FROM turba_objects WHERE (object_type = ? AND owner_id = ?) [pid 25755 on line 166 of "/opt/horde/turba/lib/Driver/sql.php"] Apr 12 15:22:25 HORDE [debug] [turba] Max memory usage: 2883584 bytes [pid 25755 on line 333 of "/usr/share/php/Horde/Registry.php"] Apr 12 15:22:25 HORDE [debug] [turba] Wrote session data (id = 82635f3ca4552932271d46828f2f2946) [pid 25755 on line 212 of "/usr/share/php/Horde/SessionHandler/memcache.php"]

I am still unable to reproduce this even with the supplied s

Sat, 12 Apr 2008 15:26:51 +0000

I am still unable to reproduce this even with the supplied source config. This is what I am doing: I changed the relevant values in my sources.php file, then I attempted to search my address book for some names. The results of the search are displayed as expected for me... i.e. all field values look correct. This is also true when I just "browse" the address book as well. Can any other dev duplicated this issue?

Hi, to be sure that I havent old or corrupted files in the

Sun, 13 Apr 2008 16:06:37 +0000

Hi, to be sure that I havent old or corrupted files in the turba directory I replaced it with a fresh checked out. But there it is the same. Another point is, that only the list of the search function is wrong. It I browse the addressbook all is displayed correctly.

I tested a little bit more. This wrong mapping for the searc

Sun, 13 Apr 2008 20:28:15 +0000

I tested a little bit more. This wrong mapping for the search result list happens only for a mapping to a foreign sql source. If I use the turba sql table for the addressbook it works correctly, although I use there the same mapping for the composite field 'name'.

I'm wondering if this might have something to do with the co

Sun, 13 Apr 2008 23:45:42 +0000

I'm wondering if this might have something to do with the column sort order and / or the name_format pref. Can you provide what values you are using for these? Does it occur with different values? (Admittedly grasping at straws here...)

Hi, I suspected the same. I tested with all three name_form

Mon, 14 Apr 2008 09:06:39 +0000

Hi, I suspected the same. I tested with all three name_format value. last_first, first_last and nothing. But the name field didnt change. Then I went on to the sort fields in the source configuration. There was only name and email, but that changed nothing. I tested, to be sure, the charset setting, changed one time the source to utf-8 -> no change. Now the interesting part. In the user preferences I changed the settings for the columns that are displayed for that source and the sort order. Now there was an impact: the name field was build by the last_name and one of the phone fields. Seems that there is the reason of the disorder. But I couldnt get the reason in the code.

Ok. I figured out what the issue is. It's caused by mappi

Mon, 14 Apr 2008 19:15:20 +0000

Ok. I figured out what the issue is. It's caused by mapping the same db field (id in your case) to two separate turba fields (__key and __uid). In your specific case you need to either add a new field for uid, or if it's a read-only source then don't map __uid to anything. But they need to be separate fields. In the more general sense, this *is* still a bug since this would occur with any db field that is mapped to two or more turba fields.

Fixed in HEAD and merged.

Tue, 15 Apr 2008 04:13:36 +0000

Fixed in HEAD and merged.

When can she work at downtown

Mon, 27 Jul 2009 18:35:11 +0000

When can she work at downtown