[Tickets #6517] Re: Export to ldif - data has no cn attribute

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/6517
-----------------------------------------------------------------------
 Ticket             | 6517
 Updated By         | herbert at linuxhacker.at
 Summary            | Export to ldif - data has no cn attribute
 Queue              | Turba
 Version            | 2.2-RC3
 Type               | Bug
 State              | Unconfirmed
 Priority           | 1. Low
 Milestone          | 
 Patch              | 
 Owners             | 
-----------------------------------------------------------------------


herbert at linuxhacker.at (2008-03-23 08:32) wrote:

> What about when sources.php has a more complex definition of 'name'?  

I saw this definition, but why there is no attribute key 'name' available
in the parameter $data of Horde_Data_ldif::exportFile? I used also the
lib/tests/ldif_exportFile.phpt testscript. The testdata always containing a
'name' key - my real data not.

In my unterstanding the config/source.php definitions are currently not
used in lib/Data/ldif.php and i think, the 'name' attribute should be
available before calling 

        $ldif->exportFile(_("contacts.ldif"), $data, true);

in data.php. My patch is only a workaround. With this patch, I can see the
correct names in Thunderbird with the import Turba addressbook data. I
created some screenshots from the imported Horde data in Thunderbird, see

http://www.linuxhacker.at/bugs/all/horde-turba-export-in-ldif

I write the data array to the logfile before i calling exportFile in
data.php:

    [15] => Array
        (
            [firstname] => Straub
            [lastname] => Herbert
            [middlenames] =>
            [namePrefix] =>
            [nameSuffix] =>
            [alias] =>
            [birthday] =>
            [homeStreet] =>
            [homePOBox] =>
            [homeCity] =>
            [homeProvince] =>
            [homePostalCode] =>
            [homeCountry] =>
            [workStreet] =>
            [workPOBox] =>
            [workCity] =>
            [workProvince] =>
            [workPostalCode] =>
            [workCountry] =>
            [timezone] =>
            [email] => herbert at linuxhacker.at
            [homePhone] =>
            [workPhone] =>
            [cellPhone] =>
            [fax] =>
            [pager] =>
            [title] =>
            [role] =>
            [company] => ,
            [category] =>
            [notes] => undefined
            [website] =>
            [freebusyUrl] =>
            [pgpPublicKey] =>
            [smimePublicKey] =>
        )

Should the fix be implemented in the export routine or in another place?