502282 - thunderbird addressbook does not write LDAP birthyear

Status: UNCONFIRMED

(Thunderbird :: Address Book, defect)

Description

[edwin.hoekstra]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; nl-NL; rv:1.9.1) Gecko/20090630 Fedora/3.5-1.fc11 Firefox/3.5
Build Identifier:  Thunderbird/3.0b2

birthyear is not filled when using the experimental ldap backend 

Reproducible: Always

Steps to Reproduce:
1.Create a ldap schema to handle birthday birthmonth and birthyear
2.compile tb to use experimental ldap
3.create a (ldap) card with birthday, birthmonth and birthyear
Actual Results:  
When the results are checked  with a ldap browser, the birthyear is empty.
If the value is written by hand, tb has no problem reading it.

Expected Results:  
birthyear is written by tb just like birthday and birthmonth are


I extended mozillaAbPersonAlpha.schema with the following test attrs:

attributetype ( 1.3.6.1.4.1.8506.1.2.1
        NAME ( 'birthday' )
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.8506.1.2.2
        NAME ( 'birthmonth' )
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.8506.1.2.3
        NAME ( 'birthyear' )
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

Comment 1

[Anthony]

Have you added these to your <DefaultInstallDirectory>\defaults\prefs\mailnews.js file:
    pref("ldap_2.servers.default.attrmap.BirthYear", "birthyear");
    pref("ldap_2.servers.default.attrmap.BirthMonth", "birthmonth");
    pref("ldap_2.servers.default.attrmap.BirthDay", "birthday");

Also, are you sure those are the right ID's? (They seem to clash with the evolutionPerson schema.)

Comment 2

[edwin.hoekstra]

Thats correct. There was/is no mozilla schema known by me for those syntaxes, so I had to create or borrow one. I choose for the last option.
Thats why I mentioned these schema items here.

Comment 3

[Anthony]

Ordinarily I'd point you at the Mozilla AB LDAP schema, except that it's significantly out-of-date (2008):
    https://wiki.mozilla.org/MailNews:Mozilla_LDAP_Address_Book_Schema

This one isn't an official schema but it is pretty much up-to-date (it's also in OpenDS format, so may need to tweak it slightly):
    http://www.2bitprogrammers.com/ldap/99-mozillaAb.ldif.txt
via
    http://www.2bitprogrammers.com/ldap/ab-index.html

Good luck.

Comment 4

[eldeh]

The following addition to the mozillaAbPersonAlpha.schema worked for me, when reading from an openLDAP server:

--- snip ---
# 1.3.6.1.4.1.13769.6.x - Mozilla AB 'Birthday' tab

attributetype ( 1.3.6.1.4.1.13769.6.1 NAME 'birthday'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.13769.6.2 NAME 'birthmonth'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.13769.6.3 NAME 'birthyear'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
--- snap ---

Comment 5

[eldeh]

To reproduce the behaviour of my comment above, I converted the LDIF file that TB 3.1 exported, by following Perl script, before I added it to the LDAP server:

--- snip ---
#!/usr/bin/perl -pi

use MIME::Base64;

s/^dn:: (.*)$/"dn: " . MIME::Base64::decode($1)/e;

s/^(dn:.*), (.*)$/$1\\, $2/;
s/,mail=/+mail=/;
s/^dn:.*$/$&,o=Familienadressbuch,ou=AddressBooks,dc=young-gods/;
s/^modifytimestamp:/#modifytimestamp:/;

s/^c: Deutschland$/c: DE/;
--- snap ---

Comment 6

[Anthony]

I'd recommend caution when using those LDIF exports (from Thunderbird's Address Book's Tools/Export... menu).

Company cards are generally broken because Thunderbird does not create a cn in their dn, since most company cards (at least in my case) don't have any first name/last name details. If you don't get an error when importing the LDIF file you'll likely find that the company cards have overwritten each other, with the last company card in the file being the winner.