157926 - Change LDIF import/export so it is compatible with 'Official Mozilla LDAP schema'

Status: RESOLVED FIXED

(MailNews Core :: LDAP Integration, defect, P3)

Description

[Roland Felnhofer]

To have the possibility to use the Mozilla LDIF export as a source for creating
LDAP server entries which following modifications are needed.

Change:

objectclass: mozillaAbPersonObsolete	-> objectclass: mozillaOrgPerson
xmozillanickname			-> mozillaNickname
xmozillausehtmlmail			-> mozillausehtmlmail
xmozillausehtmlmail: true		-> mozillausehtmlmail: TRUE/FALSE (uppercase)
modifytimestamp: 0Z			-> remove
mozillaHomeCountryName			-> mozillaHomeFriendlyCountryName
c					-> co
workurl					-> mozillaWorkUrl
homeurl					-> mozillaHomeUrl
custom1					-> mozillaCustom1
custom2					-> mozillaCustom2
custom3					-> mozillaCustom3
custom4					-> mozillaCustom4

Add:

Possibility to define DN. So 'cn' + 'mail' is not hardcoded anymore.

Comment 1

[Roland Felnhofer]

Hi Brice,

may be we should check via newsgroup if there are really a lot of admins out
which would mind to migrate immediately from the old LDIF export format to the
new schema.
If there is no (or very few) response we should re-think if the effort of
implementing this migration path makes sense. Maybe we can simply provide this
people with a simple perl script which would migrate the old attributes into the
new ones?

If we have to add migration code into Mozilla we should already define how long
(how many releases) it will stay until it gets removed from the code again.
Second I would propose to call the preference something like
'use_ldap_legacy_structure' or 'use_ldap_legacy_schema'. If it is needed it
could be added to then by the user/admin into the prefs file and set to true but
by default it's not there.

Comment 2

[Roland Felnhofer]

*** Bug 146142 has been marked as a duplicate of this bug. ***

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Let's hold off on making these changes until all the feedback on this schema is in.

Comment 4

[Kristof Petr]

There is renundant code in

mozilla/mailnews/import/text/src/nsTextAddress.cpp
mozilla/mailnews/addrbook/src/nsAddressBook.cpp

can someone from insiders with good knowledge of Mozilla
sources clean it, please?

After that the final patch will be short and neat.

Comment 5

[Kristof Petr]

Attachment: nsAddressBook.cpp Patch v 0.1

Exported ldif is now full compliant with Official schema
and can be directly injected to ldap server with ldapadd
tool.

Comment 6

[Chan Min Wai]

should this be change as well

Comment 7

[Chan Min Wai]

   if (!displayName.IsEmpty()) {
     cnStr += NS_LITERAL_STRING("cn=") + displayName;
-    if (!email.IsEmpty()) {
-      cnStr += NS_LITERAL_STRING(",");
-    }
+    cnStr += NS_LITERAL_STRING(",");
   }
 
-  if (!email.IsEmpty()) {
-    cnStr += NS_LITERAL_STRING("mail=") + email;
-  }
+// Append ou=abook, its universal
+  cnStr += NS_LITERAL_STRING("ou=abook");
 
   rv = AppendProperty(aProperty, cnStr.get(), aResult);
                                  ^^^^^^^^^^^
something should be change here right...

I'm having some problwm when I use this patch on 1.1 source...

Comment 8

[Chan Min Wai]

Sorry that is not the realy Problem on comment #7

The Problem is on this line 
+//  {kLastModifiedDateColumn, "modifytimestamp", PR_FALSE},

If this line is removec, then you will have a problem on exporting.
How could we remove That?

Is there something need to be change as well.
from what I saw in nsAddressBook.cpp
There is still a few line with the Old Export name (xmozilla). I don't know what
they are up to and I'm not that sure.

please check and see if we could catch the 1.2 final.

Comment 9

[John Woodell]

A few comments regarding the initial comments for this bug:

# xmozillanickname            -> mozillaNickname
# xmozillausehtmlmail: true   -> mozillausehtmlmail: TRUE/FALSE

Lowercase 'true/false' will create problems for all who try to import.

The AB should accept both the old and new names, and I think these old 
'xmozilla...' names should be used, given that M$ outlook import looks for 
these as well as 'xmozillaconference' and 'xmozillauseconferenceserver'.
see: http://www.openldap.org/faq/data/cache/293.html

# modifytimestamp: 0Z         -> remove

absolutely

# c                           -> co

what is the problem here?

# workurl                     -> mozillaWorkUrl
# homeurl                     -> mozillaHomeUrl
# custom1                     -> mozillaCustom1
# custom2                     -> mozillaCustom2
# custom3                     -> mozillaCustom3
# custom4                     -> mozillaCustom4

These all work great currently, with the old names,
so the AB needs to accept both old and new names.

Comment 10

[John Woodell]

This attribute has been defined in the 'official' schema,
and the '-' will not work (with OpenLDAP anyway).

mozilla_AimScreenName   ->   nsAIMid

Comment 11

[Roland Felnhofer]

John, in respect of "... and the '-' will not work (with OpenLDAP anyway)..." 
please see 
http://bugzilla.mozilla.org/show_bug.cgi?id=116692#c70

Comment 12

[Chan Min Wai]

Is This still usefull?
I find that the code is changed.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

Note that before we land this, we also need to patch the import code.  (Yeah,
these attributes are hardcoded in three different places; yuck!).

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: nsAddressBook.cpp patch, v0.2

Changes since v0.1:

* fixed so it builds against the trunk
* reverted includeForPlainText attribute on mozillaUseHtmlMail to false (not
sure why this was changed in the first place).
* put mail= back into the dn, because otherwise we have to deal with collisions
when you have two people named "John Smith" in the same addressbook

Issues still needing to be sorted out: 

* need an import patch to match this export patch

* need to file another bug to actually export modifytimestamp correctly, rather
than just getting rid of it

* need do better on the dn.  A card might contain, for example, only a screen
name, or only an email address.  We could do that here or file a separate bug.

* need to verify the inclusion of ou=abook.  I'm not against it, I'd just like
to understand a little more about why it's a good idea.

Comment 15

[John Woodell]

Even though most LDAP admins will be able to deal with whatever attributes are 
exported, the exact names used are important because...

a) People will assume that these are the attributes they should have listed
   first in their schema files, in order to have them show up in mozilla AB.
   (curently, this is not the case, but should be fixed in bug 157925)

b) When users modify their schema files to list mozillausehtmlmail first
   (instead of xmozillausehtmlmail) other clients wil no longer find it.
   I recall that netscape 4.x and outlook both use xmozillausehtmlmail 
   and xmozillanickname.

In summary, I think we should export published atribute names from person,
organizationalperson and inetorgperson as well as those that have been adopted
by other client (especially outlook) so that users that tweek their schema to
be mozilla aB friendly will still be compatible with other clients. If any of
the 'adopted' attribute names are in a standard issue Active Directory serve,
the mozila AB should export those names as well (an not use the mozilla+ names
in the latest verson of the schema).

Comment 16

[Roland Felnhofer]

(In reply to comment #15)

> In summary, I think we should export published atribute names from person,
> organizationalperson and inetorgperson as well as those that have been adopted
> by other client (especially outlook) so that users that tweek their schema to
> be mozilla aB friendly will still be compatible with other clients. If any of
> the 'adopted' attribute names are in a standard issue Active Directory serve,
> the mozila AB should export those names as well (an not use the mozilla+ names
> in the latest verson of the schema).

As stated in bug #116692: I don't agree that we have to follow used attributes
as long as they are not defined in any RFC or officially published as 'private'
attributes of an application. It must not be our problem if Microsoft used
whatever private attributes which have never been publish officially. Everybody
moans about the dictate and dominance of Microsoft. They do a lot of great stuff
and they do a lot of junk. We don’t have to follow them only because it’s Microsoft.
What are you afraid of? That a single person will or will not switch to Mozilla
because of 'xmozillanickname' or 'xmozillausehtmlmail' - I defiantly don't
believe that!
The attribute sub-string 'xmozilla' is an indication for me that it is not a
Microsoft attribute. It indicates that it is a Netscape (Mozilla) attribute
which was never officially announced as such - so it's up to Netscape (Mozilla)
to change it.

We define a schema for Mozilla which suites best the needs of Mozilla and it is
compliant to officially defined attributes. Who ever wants can follow. We must
not believe that Mozilla becomes more popular because it mimics Microsoft the
best way.

As soon we have an official schema we have the obligation to stick to it.   

Comment 17

[John Woodell]

(In reply to comment #16)

I don't really care that much about these few attributes. They have been in use,
and it seems like it would be nice it outlook clients were able to use the
same directory to click on a URL, which could link to an org chart from a 
group record (or something like that), but I don't plan to use Outlook myself.

There are many applications that define their own LDAP schema, but then this
information is hidden from standards-based clients. I don't see the problem
with creating an attribute name called 'url', there should be one. I will also
continue to use the attribute 'department' because it works in mozilla now.
It just so happens that Redmond created a definition for it, so could we.

Comment 18

[John Woodell]

I just did some testing with the 'Get Map' button and various countries.

Using 'US of A', 'United States of America' and 'Estatos Unidos' I got...

  Error Code: 400 \n\n mqs.searchReq did not return out array

Using 'US', 'USA' and 'United States' I got a nice map.

Having a bogus country will break a perfectly good address,
so I suggest that we not use 'co' in the schema, but we instead 
export and read 'c' even thought the field in the GUI is really long.
Maybe the GUI can be updated in post 1.0, maybe like this...

           City: [____________________]  State: [___]
Zip/Postal Code: [__________________]  Country: [___]

Comment 19

[John Woodell]

(In reply to comment #16)

The following are published, do you consider the following private?

http://msdn.microsoft.com/library/en-us/adschema/adschema/a_preferredou.asp
http://msdn.microsoft.com/library/en-us/adschema/adschema/a_department.asp
http://msdn.microsoft.com/library/en-us/adschema/adschema/a_company.asp

Comment 20

[William Bumgarner [:zsinj]]

*** Bug 146367 has been marked as a duplicate of this bug. ***

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

I believe that this bug is, to some approximation, fixed.  Please file new bugs
with specific schema / code related issues; 1 per bug.