On Mi, 2011-03-16 at 08:44 +0000, Thomas Pequet wrote: > > 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
I don't understand. How is that setting related to the earlier tests? Perhaps I don't understand the meaning of this setting. My understanding so far was that it is a server-side setting which somehow overrides the sync mode requested by the client. Is that correct? If not, what does that setting really do? What you say above makes it sounds like the setting is taken from the client's sync mode. If so, why have that setting at all if the client can change it at any time? Anyway, the setting seems to be irrelevant. It seems I cannot get the server to apply an update to calendar data with a Replace command at all. How can we debug this? Bye, Patrick > 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
