| Summary | Export to ldif - data has no cn attribute |
| Queue | Turba |
| Queue Version | 2.2-RC3 |
| Type | Bug |
| State | Resolved |
| Priority | 1. Low |
| Owners | Chuck Hagenbuch <chuck (at) horde (dot) org> |
| Requester | herbert (at) linuxhacker (dot) at |
| Created | 03/22/2008 (50 days ago) |
| Due | |
| Updated | 04/27/2008 (14 days ago) |
| Assigned | 04/23/2008 (18 days ago) |
| Resolved | 04/27/2008 (14 days ago) |
| Attachments | |
| Milestone | |
| Patch |
State ⇒ Resolved
Assigned to Chuck Hagenbuch
Fixed in CVS:http://lists.horde.org/archives/cvs/Week-of-Mon-20080421/077793.html
> Seems like this is an export bug; composite fields should be included
> in the export, right?
Yes, I think. You can see a full error description on my homepage with screenhots from the Thunderbird Addressbook (with and without patch).
http://www.linuxhacker.at/bugs/all/horde-turba-export-in-ldif
State ⇒ Feedback
Seems like this is an export bug; composite fields should be included in the export, right?> 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@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?
What about when sources.php has a more complex definition of 'name'? The default definition is:
'name' => array('fields' => array('namePrefix', 'firstname',
'middlenames', 'lastname',
'nameSuffix'),
'format' => '%s %s %s %s %s',
'parse' => array(
array('fields' => array('firstname', 'middlenames',
'lastname'),
'format' => '%s %s %s'),
array('fields' => array('firstname', 'lastname'),
'format' => '%s %s'))),
Patch ⇒
Milestone ⇒
Queue ⇒ Turba
Summary ⇒ Export to ldif - data has no cn attribute
Type ⇒ Bug
Priority ⇒ 1. Low
State ⇒ Unconfirmed
The exported ldif data has no valid cn attribute. This data, imported in Mozilla Thunderbird, has no correct display name. Example:
dn: cn=,mail=herbert@linuxhacker.at
should be:
dn: cn=Straub Herbert,mail=herbert@linuxhacker.at
This patch works for me:
--- lib/Data/ldif.php.orig 2008-03-22 13:07:21.000000000 +0100
+++ lib/Data/ldif.php 2008-03-22 13:13:48.000000000 +0100
@@ -182,6 +182,10 @@
$recordData = '';
$recordCn = '';
$recordMail = '';
+ // Straub construct name from firstname and lastname
+ if (!array_key_exists('name', $row)) {
+ $row['name'] = sprintf("%s %s", $row['firstname'], $row['lastname']);
+ }
foreach ($this->_mozillaAttr as $value) {
if (isset($row[$mozillaTurbaMap[$value]])) {
// Base64 encode each value as necessary and store it.