summaryrefslogtreecommitdiff
path: root/src/backends/evolution/EvolutionCalendarSource.cpp
diff options
context:
space:
mode:
authorPatrick Ohly <patrick.ohly@intel.com>2010-02-23 17:17:46 +0100
committerPatrick Ohly <patrick.ohly@intel.com>2010-02-23 21:24:14 +0100
commit2a8a2abaac4f5dd0ad2b43805cdd67633267915f (patch)
tree81491c6a068f529d9658c5080a8c427100f66049 /src/backends/evolution/EvolutionCalendarSource.cpp
parent54980b84143b03a07f46b6d3f9a6474831bc21e4 (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.cpp21
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)