226221 - home and work mail address mapping Issues for AB Palm Sync Conduit

Status: RESOLVED WONTFIX

(MailNews Core Graveyard :: Palm Sync, defect)

Description

[Scott MacGregor]

Address Book Palm Sync Conduit has some mapping issues. 

I need to get more details on this but I think it was an issue with address
fields getting mapped to the wrong address field (home vs. work?) on the client.

Comment 1

[David :Bienvenu]

I tried this - home and work addresses came through correctly. We'll need more
info to figure out what's going on here.

Comment 2

[David :Bienvenu]

OK, I tried this again, and I did get my home address in Mozilla set to the work
address on the palm. Time to grovel through the code.

Comment 3

[David :Bienvenu]

what I've found is that the palm conduit sdk (4.03, the latest version) only
supports one address field, and Mozilla uses the personal address for that
address field. Unfortunately, the palm os I'm running (5.2.1) treats that
address as a work address, as near as I can tell.

Comment 4

[Robert Accettura [:raccettura]]

Bug 205952 I think is related, as you can loose data because of mapping
inconsistancies.

I've lost data for not being aware of that one.  Hence my request for a mention
to be in the release notes (cost me about 1 hour of figuring out what I lost,
and finding tha data).

My suggestion would be (for PDA's with 1 address field):

If Mozilla has only 1 address (work || home):
   sync that address
If Mozilla has both addresses (work && Home):
   use GUI Pref to decide which address to use, and put second attached as a
note to the address

That way, there is no dataloss.  All data is there.  

When creating the note, it should contain something like:

!  Auto-Generated
!  Preserve format if modify to ensure safe sync
[Address:  Work]
1 Avenue of the Americas
New York, NY, 00000-0000
United States

The two "!" lines, to note the user that the address is in a particular format
so mozilla can read it, it should be copied into the note section of the mozilla
address book, so no data loss, and noted to the user via a dialog.


This method would ensure no dataloss, and hopefully prevent issues.

The user could decide which goes into the address field of the palm by default,
and which into the note.

It's a tough issue, Palm doesn't have very great documentation.  And Mozilla's
address book is slightly different than the Palm Address book.  But this way, I
think we can preserve all data.

Comment 5

[David :Bienvenu]

That's a good idea about how to avoid the data loss. I doubt that this is
related to bug 205952 in any technical way, except that they both involve data
loss. I could be wrong, of course.

When you say "Note", is that the same as Custom fields in the Contacts app? Does
the old Palm Address Book app have notes fields?

Comment 6

[Robert Accettura [:raccettura]]

it's not a field, but "Details..."  --> "Note" buttons will bring you to an
attached note.

I've seen Palm Desktop interact with these notes, so I know it can be done.

I'm pretty sure the bugs are related.  My reasoning is that the data that I've
tracked with this issue tends to have fields on one device, that isn't on the
other.... hence mapping.  

What's needed, is a fallover method (perhaps using the notes field) to ensure
that data is always captured, so none is lost.

Post finals, when I get some free time, I'll be happy to investigate this
further if you like.... just to much time for this particular issue to be tested
in detail now.  Lots of sinareo's... and restoration can be a pain to at times
(based on past experiences).

Comment 7

[David :Bienvenu]

Attachment: partial fix

this patch makes it so we honour a hidden pref, "mail.palmsync.useHomeAddress".
It defaults to true. If it's false, we'll use the mozilla ab work address as
the palm address. I've verified that this works when copying a card from Moz AB
to the Palm. I haven't looked into what happens when you go the other way yet.

I might actually want to figure out a way to default this pref to false if the
palm os version is 5.0 or greater, because in that case it seems that we want
the work address.

I haven't addressed the Note issue.

Comment 8

[Robert Accettura [:raccettura]]

David,

What if the user only enters 1?

I think there are many instances, where I have only a work address, or only a
home address.

If I have it default to home, and I only have a work address... will it sync
that?  Or vice versa?

I think the pref should be giving priority to home vs. work.  

Or else, all data has to be entered into home or work, regardless of actual
correctness.

Then perhaps in part 2 of this fix, implement the note deal... so that the
priority item, goes in the address book, and the 2nd class address, goes into
the note?

Just an idea.

Secondly.  It might be a better implementation if the user can decide this on a
case by case basis.  For example:

I contact my boss mostly in the office, rarely at home.  So I want the business
info 1 click away, and the home info, in the note.

My friend lives at home, so I want his home address in the address book, and his
work address in the note.

I think many would want something along those lines.  So perhaps, rather make
this pref, a "default" setting.  And allow the user to select on the address
card itself when PalmSync is installed (mockup to follow).

That way, it defaults ot the config as set by this pref.  But the user can
perhaps override.  I think it would provide a very intuitive inteface.  Minimal
clicks, as the user can define how to default the palm sync to their perfered
method.  And perfect sync each time.

Comment 9

[Robert Accettura [:raccettura]]

Attachment: Address Book Mockup (rja concept - comment #8)

Comment 10

[David :Bienvenu]

Robert, I agree in principle with your comments about preferring one address
over the other. However, because of the incompatibility issues between CDK 4.03
and Palm OS 5.x, on that platform, if the user says to prefer work address, but
has no work address for a card, the Palm will show the Moz AB home address as a
work address. (I assume Palm OS 4.0 just calls it "Address"? ) So, I'm torn. To
work around this, I'd need to have a 4-state pref, always use home, always use
work, prefer work, prefer home. Always use home probably wouldn't be used, but
should be there for consistency's sake.

Comment 11

[Robert Accettura [:raccettura]]

Hmm.  I'm curious now.

Using Palm OS Simulator (Palm OS 5.2), I don't see a signifigant change in data
fields from the old Palm OS 4 to it.  In all honesty, I don't see any at hand.

Both are "Address", "City", "state", "zip"... etc.

Address book 4.1 for the Palm OS 4 version.

and 4.5 for the OS 5 version.

I don't see two for either.  

Is this a proprietary address book your talking about?

My Palm IIIxe runs Palm OS 4.1, so does my Clie.  The two are similar (slight
differences with sony mods).  The Palm OS Simulator has Palm OS 5.  And the same
address book pretty much.  

Perhaps we can discuss on AIM sometime, and figure out what's what.  From what I
see, there is no difference between OS 4, and OS 5 Address book, in this aspect.
 Palm Desktop reflects that as well.  

Comment 12

[David :Bienvenu]

I'm talking about the Contacts App, which replaces Address Book on my Tungsten E
(as I understand it). It has both home and work address fields, and the CDK has
only one address field. The Contacts App seems to take the address field in the
CDK structure and map it to work address.

Comment 13

[Robert Accettura [:raccettura]]

Verified that:
http://205.141.210.148/SRVS/CGI-BIN/WEBCGI.EXE/,/?St=94,E=0000000000368163464,K=2195,Sxi=6,useTemplate=Case.tem,CASE=25782

There apparantly part of another branch of palm development.  When downloading
Palm Desktop, you see:

"Tungsten E, Tungsten T3, and Zire 21 users should use the version of Palm
Desktop software which came with their handheld."

I take it, the rest of Palm OS PDA's, use the standard Address Book (will try to
verify that for you).

I would suggest, perhaps, that development be oriented at the rest of the Palm
Users (using Address as their Address Book), and perhaps RFE support for Contacts.

Address appears to be the default app on all other Palm OS systems, by Palm and
Sony (and I'm sure others).  Handspring IIRC used a third party product, but it
synced the same.

Comment 14

[Robert Accettura [:raccettura]]

Sorry, should have added:

There is apparantly no support for detecting what's installed, or Palm would
have 1 Palm Desktop download, rather than turn the Contacts users away,
referring them to the CD that came with their PDA.

I don't see any mention on how to detect it.  And there's a custom Palm Desktop
version for it.

Perhaps the solution would be for the Palm Sync Installer to ask what's used? 
Or to check the Palm Desktop directory, and check what version is installed.

Comment 15

[David :Bienvenu]

Attachment: fix for problems introduced by previous patch

in some situations, like HH -> PC syncs, the home address field wasn't getting
synced. This patch fixes that, and adds some PR_Logging abilities (not fully
turned on yet).

Comment 16

[Robert Accettura [:raccettura]]

The previous fix introduced dataloss (loosing street address of palm synced data).

Nominate for blocking 1.6 until new patch is checked in.  It would be quite ugly
for anyone using palmsync to loose their street addresses in 1.6 (I assume
PalmSync is shipping in 1.6).

Comment 17

[Robert Accettura [:raccettura]]

It shipped.  AFAIK the patch didn't make it.

Comment 18

[David :Bienvenu]

Attachment: fix for first time sync after syncing with a conduit that misses fields

the 4.x conduit skips the cell phone number. This fix makes it so if we're
doing a first time sync after switching to the tbird conduit from the netscape
conduit, we allow a couple fields to be different w/o creating dup cards on
both pc and hand held.

Comment 19

[Robert Accettura [:raccettura]]

David,

Sync with latest xpi you posted worked very well... this bug is still of course
an issue (home gets synced, but I sometimes need the work address).

Though that whole thing with stuff not being synced initally is gone!

Comment 20

[Wayne Mery (:wsmwk)]

is it just a matter of checking this in?

Comment 21

[Wayne Mery (:wsmwk)]

David, Robert, Scott,

Does bug and patches pertain to only suite? (comment 18 hints this is now for TB)

What is current state of the patches?

Is there potential fallout related to comment 18 with possible duplicate records? 

I assume this was left open for further work. Do we know what work remains to be done? See also bug 321991.

Also for the most current version of conduit, is the hidden pref "mail.palmsync.useHomeAddress" (comment 7) still useful? Or, was it for a condition whose problem has gone away?

Comment 22

[Edgardo]

Any update on this issue or 321991 ?

Regarding the selection of Home vs Work addresses for sync:
Outlook has a "This is the mailing address" button. If a contact contains a single address, then the button is "pressed" for that address automatically. Otherwise, the user has to click the button for one of the three available addresses (home/business/other).
In the "Field Mapping" form of the synchronization software, Palm's address fields are manually mapped to Outlook's mailing address fields. 2nd and 3rd addresses are manually copied to the "Notes" field of Outlook, ... or lost.

A similar button in TB would address most of the problem.
Keeping a second address would be a nice bonus.

Comment 23

[Wayne Mery (:wsmwk)]

David and Robert 

* It's not clear to me what work was left to be done on the patch, attachment 142262 [details] [diff] [review] - can you summarize? (I see the previous attachment was last checkinn from this bug, but there have been palmsync checkins from other bugs since then, eg bug 232438, bug 233945, bug 205902, bug 231615)

* What is comment 18 all about?  NS -> suite?  Do we still need to worry about that. 


(In reply to comment #22)
> Any update on this issue or 321991 ?

not yet


> A similar button in TB would address most of the problem.
> Keeping a second address would be a nice bonus.

An extension to expose the preference STM the most reasonable route.

Comment 24

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]