When can she work at  downtown

Fixed in HEAD and merged.

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.

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.

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...)

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'.

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 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?

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"]

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!

Sounds like a consequence of Jan's recent changes.

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