diff options
author | Patrick Ohly <patrick.ohly@intel.com> | 2010-02-23 17:17:46 +0100 |
---|---|---|
committer | Patrick Ohly <patrick.ohly@intel.com> | 2010-02-23 21:24:14 +0100 |
commit | 2a8a2abaac4f5dd0ad2b43805cdd67633267915f (patch) | |
tree | 81491c6a068f529d9658c5080a8c427100f66049 /src/backends/evolution/EvolutionCalendarSource.cpp | |
parent | 54980b84143b03a07f46b6d3f9a6474831bc21e4 (diff) |
EvolutionCalendarSource: change tracking when deleting a child event
When removing a child event (RECURRENCE-ID set), the behavior of EDS
for the parent event (without the RECURRENCE-ID) is
undefined. Client::Source::ical20::testLinkedItemsRemoveNormal assumed
that the parent's LAST-MODIFIED was not affected.
Nightly testing recently showed that at least some EDS versions modify
the parent when removing a child. More specifically, they add an
EXDATE to the parent for the recurrence that was removed. This is
reasonable. The puzzling part is that this test failure was not
observed earlier. This might be because the test could be timing
dependent: if creating the parent and removing the child fall into the
same second, then the parent is not considered as modified.
This patch modifies the test so that it passes both when the parent is
updated and when it isn't.
In addition, this failure points towards another problem: if a server
like ScheduleWorld deletes a child event on a client, it first sends
an update for the parent and then the removal request for the
child. We should not report the parent as modified during the next
sync. Again, depending on the timing, this may or may not have
happened.
This is based on the assumption that the server knows about
child/parent events and does the right thing. If the parent event was
not modified on the server when removing the child, then with this
patch we are not going to fix that in the next sync. Such servers
should be fixed.
This patch therefore adds a check to testLinkedItemsRemoveNormal for
the change tracking and fixes EvolutionCalendarSource::removeItem() so
that it updates the change tracking when necessary. Because
TrackingSyncSource is not prepared to deal with a removal that has
side effects, its tracking config node must be made accessible for
this to work.
Diffstat (limited to 'src/backends/evolution/EvolutionCalendarSource.cpp')
-rw-r--r-- | src/backends/evolution/EvolutionCalendarSource.cpp | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/src/backends/evolution/EvolutionCalendarSource.cpp b/src/backends/evolution/EvolutionCalendarSource.cpp index abafb8aa..8c7a8b8e 100644 --- a/src/backends/evolution/EvolutionCalendarSource.cpp +++ b/src/backends/evolution/EvolutionCalendarSource.cpp @@ -564,6 +564,27 @@ void EvolutionCalendarSource::removeItem(const string &luid) } } m_allLUIDs.erase(luid); + + if (!id.m_rid.empty()) { + // Removing the child may have modified the parent. + // We must record the new LAST-MODIFIED string, + // otherwise it might be reported as modified during + // the next sync (timing dependent: if the parent + // was updated before removing the child *and* the + // update and remove fall into the same second, + // then the modTime does not change again during the + // removal). + try { + ItemID parent(id.m_uid, ""); + string modTime = getItemModTime(parent); + string parentLUID = parent.getLUID(); + updateRevision(getTrackingNode(), parentLUID, parentLUID, modTime); + } catch (...) { + // There's no guarantee that the parent still exists. + // Instead of checking that, ignore errors (a bit hacky, + // but better than breaking the removal). + } + } } icalcomponent *EvolutionCalendarSource::retrieveItem(const ItemID &id) |