View Issue Details

IDProjectCategoryView StatusLast Update
0002786SOGoBackend Calendarpublic2014-05-28 15:40
Reporterstengel Assigned Tofrancis  
Status resolvedResolutionfixed 
Product Version2.2.3 
Target Version2.2.4Fixed in Version2.2.4 
Summary0002786: Participant status not properly updated via CalDAV

When an attendee changes his status (i.e. responds to an invitation) via CalDAV, the new status isn't properly reflected on all the other user's copy of the event. The changed status only shows up for the organizer/other attendees if they keep their copy of the event in a specific calendar, usually their "Personal Calendar". If the event is stored in another calendar, the participant status won't change.

If the invitation response is submitted using the Web-Frontend instead of CalDAV, the status change propagates as expected.

Steps To Reproduce
  1. Log in as User "Alice" in the SOGo Web interface
  2. Create several new calenders if there's only one
  3. Create a new event in one of the calendars, preferrably not the "Personal calendar"
  4. Add User "Bob" to the list of participants and save.
  5. Log in as User "Bob" using a CalDAV client (e.g.
  6. Accept the pending invitation from "Alice" via CalDAV
  7. Inspect the participant status as User "Alice" in the Web interface

Expected result: Alice is the organizer in this scenario, so she should see that Bob has accepted the invitation when looking at the list of participants.

Actual result: Alice sees Bob's state is still on "needs-action" (yellow bubble in the Web interface).

Additional Information

This issue arises due to the way the lookup of other user's copies of the event is implemented. The method "_lookupEvent" from SOGoAppointmentObject.m is supposed to find the copy of a given event belonging to a given user. In order to do this, is calls the method findName on all the folders of that given user and takes the first object it finds. However, the findName method doesn't always return nil in case nothing was found, but sometimes may also create new objects. More specifically, the findName method from SOGoGCSFolder.m will instantiate new objects if the currently processed request is an HTTP "PUT" operation. This also happens with attendee status updates via CalDAV, as these are announced to the server using the "PUT" command. In this case, the status update may erroneously proceed with this new object instead of searching the other calendars. Depending on which folder is searched first, the actual object may be found and the update sometimes works as expected.

The attached patch fixes the problem by rejecting new Objects from lower layers in the _lookupEvent method. However, my gut feeling is that the proper fix would actually consist of changing findName to purely lookup things instead of mingling it with object creation.

TagsNo tags attached.




2014-05-22 22:48


sogo-fix-attendee-update.patch (860 bytes)   
diff --git a/SoObjects/Appointments/SOGoAppointmentObject.m b/SoObjects/Appointments/SOGoAppointmentObject.m
index fa9b348..1712ec7 100644
--- a/SoObjects/Appointments/SOGoAppointmentObject.m
+++ b/SoObjects/Appointments/SOGoAppointmentObject.m
@@ -148,14 +148,14 @@
       object = [folder lookupName: nameInContainer
 		       inContext: context 
 		       acquire: NO];
-      if ([object isKindOfClass: [NSException class]])
+      if ([object isKindOfClass: [NSException class]] || [object isNew])
 	  possibleName = [folder resourceNameForEventUID: eventUID];
 	  if (possibleName)
 	      object = [folder lookupName: possibleName
 			       inContext: context acquire: NO];
-	      if ([object isKindOfClass: [NSException class]])
+	      if ([object isKindOfClass: [NSException class]] || [object isNew])
 		object = nil;


2014-05-28 15:40

administrator   ~0007140



Issue History

Date Modified Username Field Change
2014-05-22 22:48 stengel New Issue
2014-05-22 22:48 stengel File Added: sogo-fix-attendee-update.patch
2014-05-23 02:26 francis Target Version => 2.2.4
2014-05-28 15:40 francis Note Added: 0007140
2014-05-28 15:40 francis Status new => resolved
2014-05-28 15:40 francis Fixed in Version => 2.2.4
2014-05-28 15:40 francis Resolution open => fixed
2014-05-28 15:40 francis Assigned To => francis