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

RESOLVED FIXED in mozilla1.8beta4

Status

P3
normal
RESOLVED FIXED
16 years ago
10 years ago

People

(Reporter: roland.felnhofer, Assigned: dmose)

Tracking

Trunk
mozilla1.8beta4

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Blocks: 157928
(Reporter)

Comment 1

16 years ago
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.
(Reporter)

Comment 2

16 years ago
*** Bug 146142 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

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

Comment 4

16 years ago
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

16 years ago
Created attachment 97939 [details] [diff] [review]
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

16 years ago
should this be change as well

Comment 7

16 years ago
   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

16 years ago
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.

Updated

16 years ago
QA Contact: yulian → gchan

Comment 9

16 years ago
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

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

mozilla_AimScreenName   ->   nsAIMid

(Reporter)

Comment 11

16 years ago
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

15 years ago
Is This still usefull?
I find that the code is changed.
(Assignee)

Comment 13

14 years ago
Note that before we land this, we also need to patch the import code.  (Yeah,
these attributes are hardcoded in three different places; yuck!).
Assignee: srilatha → dmose
Summary: Change LDIF export so it is compatible with 'Official Mozilla LDAP schema' → Change LDIF import/export so it is compatible with 'Official Mozilla LDAP schema'
(Assignee)

Comment 14

14 years ago
Created attachment 165600 [details] [diff] [review]
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.
(Assignee)

Updated

14 years ago
Attachment #97939 - Attachment is obsolete: true

Comment 15

14 years ago
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).
(Reporter)

Comment 16

14 years ago
(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

14 years ago
(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

14 years ago
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: [___]
Product: MailNews → Core
(Assignee)

Updated

14 years ago
Priority: -- → P3
Target Milestone: --- → mozilla1.8beta3
(Assignee)

Updated

13 years ago
Depends on: 297967
(Assignee)

Updated

13 years ago
No longer depends on: 297967
*** Bug 146367 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

13 years ago
I believe that this bug is, to some approximation, fixed.  Please file new bugs
with specific schema / code related issues; 1 per bug.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.