> Is this "SyncEvolution -> Memotoo" setting the default for new devices?
The default setting is "both ways"
"sc-pim-B" is actually "Evolution -> Memotoo" for calendar, I think it
comes during the diffrents test you do before this test...
https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50477
Le 06/03/2011 16:52, Patrick Ohly a écrit :
On Sa, 2011-03-05 at 17:06 +0000, Thomas Pequet wrote:
Thanks Patrick
I have seen that the device
"syncevolution-3b3d8d41-71db-477b-b91a-08600a31cd93" (the 2nd) sync
only "Evolution -> Memotoo" in Memotoo:
https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50113
Each test session starts with random device IDs, as if the user had
started using MemoToo for the first time.
Does it mean that all users who want to download data from Memotoo need
to reconfigure their account?
Does it apply only to *updates* during a two-way sync? *New* items seem
to get transferred (but that might be during a slow resp.
refresh-from-server sync).
I also noticed that only calendar items were affected. The test passed
for contacts - shouldn't it also fail for those?
I'll change the testing to use fixed device IDs now, and try again. Hmm,
didn't work. I used the "syncevolution" account, device IDs sc-api-A and
sc-pim-B. The test fails, but the web interface shows "both ways" for
these two devices and calendar events.
The synchronization history for "sc-api-A" shows:
phone meeting SyncEvolution » Memotoo : Add 2011-03-06 - 16:35:42 (G.M.T.
+1)
There should also be a later entry for *updating* that item. To me it
looks like the server ignores the Replace command from the first client
(sc-api-A in this case):
https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50476
The data on the server definitely is the older item, not the update.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
