119331 - prefer html problems with LDAP servers

Status: VERIFIED FIXED

(MailNews Core :: LDAP Integration, defect)

Description

[(not reading, please use [e-mail] instead)]

there's a problem.

mork stores it as 0,1,2 {unknown, plain, html}

but on the wire, 'xmozillausehtmlmail' is a boolean.

it's either true, false or not given.

for ldif export (and import) we do this:

0 -> export nothing
1 -> export "xmozillausehtmlmail: false"
2 -> export "xmozillausehtmlmail: true"

for import, we do

"xmozillausehtmlmail: false" -> 1
"xmozillausehtmlmail: true"  -> 2

if nothing is specified, we do nothing and the default is "unknown".

right now, due to #108366, we're expecting to read "unknown", "html" 
or "plaintext" back from the LDAP server.  it would really be "true" or "false.

thanks to dmose for pointing this out

Comment 1

[John Marmion]

Well, looks like I made a bit of a mess of bug #108366. I will correct it.  So
is the 'xmozillapreferredmailformat' now redundant? 

Comment 2

[Roland Felnhofer]

Seth, sorry but what do you mean with this:

> but on the wire, 'xmozillausehtmlmail' is a boolean.
1)It is a boolean now ?
2)It should be a boolean?
3)It was a boolean before the patch?

1) NO - I have defined it as string in my schema
(1.3.6.1.4.1.1466.115.121.1.26)and everything works well! I use 'html',
'plaintext' or 'unknown' as attribute values!
2)Why?
3)I don't know WHAT it was before that patch but it didn't work. Neither with
'TRUE'/'FALSE' nor with '0','1' or '2' nor with 'html', 'plaintext' or 'unknown'.

Comment 3

[John Marmion]

Roland, I do believe there was a Mozilla AB bug regardless of how we stored the
LDAP data. But it appears that in fixing it, I also made some false assumptions
that I need to get some clarification now. Am I correct in assuming the
following:

1. Are we saying that we should be expecting  "true" or "false" from LDAP ?

2. That introducing 'xmozillapreferredmailformat' was an error and we should 
revert to using 'xmozillausehtlmail' only.

 

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

The deal is the Netscape 4.x expects the LDAP attribute to either be true,
false, or not given (unknown).  Since that represents a sizable deployed base of
users, we'd like to avoid breaking them if possible.  So to answer John's questions:

1) true, false, not given
2) I don't have a terribly strong opinion here.  Backing it out does seem a bit
cleaner, however.

Comment 5

[Roland Felnhofer]

John, Dan, 
1) OK! lets define it as Boolean (TRUE/FALSE, not set)
2) Yes! I think there is no need to have 'xmozillapreferredmailformat'
 anymore - lets remove it. It would be even more confusing.

Comment 6

[John Marmion]

Attachment: Patch

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 65619 [details] [diff] [review]
Patch 

r=[e-mail]

Comment 8

[(not reading, please use [e-mail] instead)]

Comment on attachment 65619 [details] [diff] [review]
Patch 

sr=sspitzer

I don't think john has cvs access so I'll land for him.

Comment 9

[(not reading, please use [e-mail] instead)]

fixed.  thanks for sorting this out, john (and thanks to roland for the helpful
feedback.)

Comment 10

[yulian chang]

John, Would you provide me test scenario? Thx!

Comment 11

[John Marmion]

Attachment: test case ldif sample

Yulian,
you need access to an LDAP Directory Server which uses the attribute
"xmozillausehtmlmail". 

1. Set the value of "xmozillausemtmlmail" attribute of 3 different entries in
the LDAP Directory Server to "true", "false" and blank. Ensure a fourth entry
does not contain this attribute.
2. Run a simple query against this LDAP Address Book which returns all 4
entries.
3. Select the Properties of each entry. Ensure that the Mozilla Address Book
attribute "Prefers to receive message formatted as" is set to "HTML" for
"true", "Plain Text" when "false" and "Unknown" for the other two cases.

Alternatively, I have attached an ldif file which has three different entries
which should set Mozilla attribute to "HTML", "Plain Text" and "Unknown".
Import this file and test the corresponding values.

Comment 12

[yulian chang]

20020910 trunk build on Win2K

Verified with attached ldif file.