---- Reported by jingke.zhang@intel.com 2010-04-19 19:42:54 +0000 ----

This is from http://bugzilla.moblin.org/show_bug.cgi?id=4631

   Description  From  yuering   2009-07-22 01:50:21 PST   (-) [reply]

---------------------------------
  Summary
---------------------------------
  ORG data is not consistent after two-way/slow sync between seperately updated
client and server.
---------------------------------
  Reproduce Step
---------------------------------
<1> add one contact name: Jessy, Company “Intel”
<2> two-way sync
<3> modify local contact’s Company as “Intel(PRC)”
<4> modify google server contact’s Company as “Intel(US)”
<5> two-way sync again.
    Company filed of contact “Jessy” is not consistent in client and server.
Result shows that in client, Company is still "Intel(PRC)", in server, Company
is still "Intel(US)".

Test the same step in Funambol, client updated contact information will replace
the corresponding server's contact.

------------------------
last sync outgoing data
------------------------
BEGIN:VCARD
VERSION:2.1
REV:20090722T142205Z
N:;Monday;;;
FN:Monday
X-EVOLUTION-FILE-AS:Monday
NICKNAME:
TITLE:
ORG:intelClient11;;;
ROLE:
TEL;CELL:33333333
TEL:111111111111111111111111111111
TEL;CELL:22222222
EMAIL:
URL:
X-MOZILLA-HTML:
ADR:;;;;;;
BDAY:
NOTE:
PHOTO:
END:VCARD
-------------------------
last sync incoming data
-------------------------
BEGIN:VCARD
VERSION:2.1
FN:Monday
N:;Monday;;;
TEL;CELL:33333333
TEL:111111111111111111111111111111
TEL;CELL:22222222
ORG:intelServer
ORG:intelClient11
TITLE:
NOTE:
ADR:;;;;;;
X-EVOLUTION-FILE-AS:Monday
NICKNAME:
ROLE:
URL:
X-MOZILLA-HTML:
BDAY:
END:VCARD

------- Comment #1 From Chen Congwu 2009-07-22 19:44:32 PST (-) [reply] -------

(In reply to comment #0)
Yes, if the client update the ORG field and the server update the ORG field the
same time. 
A later two-way sync, will cause the server send back a contact with *two* org
fields. The underlying eds can store them correctly but :
1) most client can't show a contact with more than one ORG.
2) During sending, synthesis will also only send the contact with one ORG (the
second ORG will overwrite the previous one).

I wonder whether it's consistent with vcard for a contact with more than one
ORG properties. If so, we may need to extend synthesis. If not, we may have to
workaroud for such case: if we receiving a server item with more than one ORG,
we may have to decide which one to store and strip others.

------- Comment #2 From pohly 2009-07-23 00:45:21 PST (-) [reply] -------

(In reply to comment #1)
> (In reply to comment #0)
> Yes, if the client update the ORG field and the server update the ORG field the
> same time. 
> A later two-way sync, will cause the server send back a contact with *two* org
> fields. The underlying eds can store them correctly but :
> 1) most client can't show a contact with more than one ORG.
> 2) During sending, synthesis will also only send the contact with one ORG (the
> second ORG will overwrite the previous one).

Our sysync_sample_config.xml contains ORG as a simple property (not an array),
so already when we receive the vCard from Google only the later ORG property is
stored in the field list and then encoded again for EDS. This matches the
capability of Evolution, which only supports one ORG.

What does Google do with two ORG properties? Is that visible in the web
interface?

> I wonder whether it's consistent with vcard for a contact with more than one
> ORG properties. If so, we may need to extend synthesis. If not, we may have to
> workaroud for such case: if we receiving a server item with more than one ORG,
> we may have to decide which one to store and strip others.

The current behavior is consistent with Evolution, so we shouldn't change the
config. As to handling the duplicate ORG, we already pick the later one. I'm
not sure whether the order is predictable, but it doesn't matter anyway: there
is no good solution for preserving both pieces of information, neither on the
client nor on the server.

I tend to close this issue as "works as intended".

------- Comment #3 From Chen Congwu 2009-07-23 00:52:57 PST (-) [reply] -------

(In reply to comment #2)

> What does Google do with two ORG properties? Is that visible in the web
> interface?
No, it only displays one ORG. I am even not sure whether it stores two ORG, but
it send the response with two ORG.

------- Comment #4 From yuering 2009-07-23 00:55:42 PST (-) [reply] -------

(In reply to comment #2)
> The current behavior is consistent with Evolution, so we shouldn't change the
> config. As to handling the duplicate ORG, we already pick the later one. I'm
> not sure whether the order is predictable, but it doesn't matter anyway: there
> is no good solution for preserving both pieces of information, neither on the
> client nor on the server.
> I tend to close this issue as "works as intended".

I agree that not preserving both pieces of information, the problem is that it
will confuse end user because client and server show different company
information.

------- Comment #5 From pohly 2009-07-23 04:20:19 PST (-) [reply] -------

(In reply to comment #4)
> (In reply to comment #2)
> > The current behavior is consistent with Evolution, so we shouldn't change the
> > config. As to handling the duplicate ORG, we already pick the later one. I'm
> > not sure whether the order is predictable, but it doesn't matter anyway: there
> > is no good solution for preserving both pieces of information, neither on the
> > client nor on the server.
> > I tend to close this issue as "works as intended".
> 
> I agree that not preserving both pieces of information, the problem is that it
> will confuse end user because client and server show different company
> information.

We might change the config so that the ORG field list is not overwritten.
Assuming that Google always displays the first ORG property, this would ensure
that we pick the same one.

Hmm, I was thinking of the "overwriteempty" config option, but it doesn't quite
fit. We would need a "overwritenonempty=false" config option.

Congwu, can you look into this? I don't think it is urgent.

------- Comment #6 From Chen Congwu 2009-07-23 18:03:53 PST (-) [reply] -------

(In reply to comment #5)
OK, I will look at this. 
> Congwu, can you look into this? I don't think it is urgent.



--- Bug imported by patrick.ohly@gmx.de 2012-08-19 20:56 UTC  ---

This bug was previously known as _bug_ 1002 at https://bugs.meego.com/show_bug.cgi?id=1002

Unknown platform unknown. Setting to default platform "".
Unknown operating system unknown. Setting to default OS "".