View Issue Details

IDProjectCategoryView StatusLast Update
0002561SOGoWeb Calendarpublic2017-08-11 17:38
ReporterChristian Mack Assigned Toludovic  
Status resolvedResolutionfixed 
Product Version2.1.1b 
Summary0002561: Can not invite to an exeption only

You have a recurrent event series.
You want to invite a speaker to one of these events.
You open the event and choose "This occurency only".
Now invite the person.
After saving, the person is invited to all events of this recurrent event series, not just to the one you wanted.

This also affects booking of rooms and other resources.
This is a severe bug.

Steps To Reproduce

1) user_A creates a recurrent event serie Friday weekly 4 times.
2) user_A saves this event serie.
3) user_A double clicks on the second Friday of this series.
4) user_A chooses "This occurency only"
5) user_A invites user_B
6) user_A saves this occurency.
=> user_B is invited to all 4 Fridays.

user_B should only be invited to the second Friday!

TagsNo tags attached.


has duplicate 0002977 resolvedludovic Problem with editing of one occurence from repeating events 
has duplicate 0003911 resolvedludovic One time modification of a recurring event invited resource, replicate to all occurences 
has duplicate 0004144 closedludovic Adding attendees in one event of a series allows him to accept all events 
related to 0002427 resolvedludovic Problem with recurrent event and delegation 
related to 0003882 new Can't dismiss missed reminders for recurring events or deleted event 




2014-02-07 12:36

administrator   ~0006519

That's not really what happens.

Yes user_Bi is added to the master event but with the declined state.

This is to avoid broken behaviour with lots of calendar clients.

Christian Mack

Christian Mack

2014-02-28 09:40

developer   ~0006584

We discussed this internally.

In order to "fix" broken clients you break the SOGo core.
So you store data that is false, display this false data in the webinterface and provide this false data to all clients, even the not broken ones.

We think this aproach is broken by design.

Instead you should do it right in SOGo core and then present the data as needed in false representation to the broken clients.

The negative side effects from our point of view are:

  • people who are invited only to one occurency, now have the ability to accept another event from this series and decline the intended one!
  • cluttering the personal calendars of invited people with declined events.
  • cluttering the resources with declined events. Think of multiple recurring events, which only need a resource from time to time. If there are more than 5 of these events, the calendar of this resource will be unusable.


2014-05-22 10:09

reporter   ~0007062

How about the following attempt at a compatible and user-friendly solution:

When making changes to the attendee list of an exception, that exception is completely removed from the recurrence (i.e., it will behave as if the entry had been deleted out of the recurrence and a new single entry had been created).

This should make the clients happy which require the entry referenced by the RECURRENCE-ID to be present (e.g. Lightning).

This should also make the users happy, which typically believe that the modified entry is unrelated to the recurrence.

BTW: Where is the RECURRENCE-ID used?



2014-06-08 15:14

reporter   ~0007158

What is currently implemented in SOGo is not intuitive to the users

  • everyone sees a decline for the user, even though the new user never declined
  • the new user sees information about the recurrence and its individual entries, not only about the single invitation (information leakage)
  • the new user can start to accept other events and thus confuse everyone
    All this just for the sake of providing some clients with a compatible view.

Let me propose a simpler, less confusing, and compatible approach:

  1. Adding a new attendee to a single event does the minimum necessary change, as any other single event change. I.e., an exception would be added which includes that additional participant. (No declined addition to the parent recurrence; this seems to work in the SOGo web interface, so no only code to delete)

  2. The invited account only gets the new event into its database, no parent (the SOGo web interface seems to be fine with this, i.e., no code needs to be added to handle this case.)

  3. If a incapable client syncs this information, either (a) the RECURRENCE-ID line is deleted or (b) a fake parent is added. The second option is slightly more complex but probably increases the compatibility when the new attendee is added to a second event of the recurrence).

Could this please be fixed?



2015-10-04 09:56

reporter   ~0008972

Are there any plans to fix this issue? I do not want to see the complete series of events when I am only invited to a single exception. The behaviour is still not intuitive in 3.2.3...



2015-10-04 10:10

reporter   ~0008973

...2.3.2 of course.



2017-05-29 14:57

reporter   ~0011842

Is there any progress regarding this issue ?

As you stated in 0004144 ( you did this by design to handle limitations in caldav clients. But you also mentioned that these limits are gone now.


2017-07-09 04:56


Any update ?



2017-07-14 17:17

administrator   ~0012103

Code has started and excellent progress was made this week. Except a commit early next week.


2017-07-18 19:59


ok thanks

Related Changesets

sogo: master 032b2fbb

2017-07-19 11:05


Details Diff
(fix) can now invite to exceptions only (fixes 0002561) Affected Issues
mod - NEWS Diff File
mod - SoObjects/Appointments/NSArray+Appointments.h Diff File
mod - SoObjects/Appointments/NSArray+Appointments.m Diff File
mod - SoObjects/Appointments/SOGoAppointmentFolder.m Diff File
mod - SoObjects/Appointments/SOGoAppointmentObject.m Diff File
mod - SoObjects/Appointments/SOGoCalendarComponent.m Diff File
mod - SoObjects/Appointments/iCalCalendar+SOGo.h Diff File
mod - SoObjects/Appointments/iCalCalendar+SOGo.m Diff File
mod - SoObjects/Appointments/iCalEvent+SOGo.m Diff File
mod - UI/Scheduler/UIxCalListingActions.m Diff File

Issue History

Date Modified Username Field Change
2013-12-19 13:59 Christian Mack New Issue
2014-02-07 12:36 ludovic Note Added: 0006519
2014-02-07 12:36 ludovic Status new => closed
2014-02-07 12:36 ludovic Assigned To => ludovic
2014-02-07 12:36 ludovic Resolution open => won't fix
2014-02-28 09:40 Christian Mack Note Added: 0006584
2014-02-28 09:40 Christian Mack Status closed => feedback
2014-02-28 09:40 Christian Mack Resolution won't fix => reopened
2014-05-22 10:09 Marcel Note Added: 0007062
2014-06-08 15:14 Marcel Note Added: 0007158
2014-11-05 08:35 Christian Mack Relationship added has duplicate 0002977
2015-10-04 09:56 thomas Note Added: 0008972
2015-10-04 10:10 thomas Note Added: 0008973
2016-11-23 20:23 francis Relationship added has duplicate 0003911
2016-12-28 15:56 ludovic Relationship added related to 0002427
2016-12-29 18:10 ludovic Relationship added related to 0003882
2017-04-11 16:04 ludovic Relationship added has duplicate 0004144
2017-05-29 14:57 teryx Note Added: 0011842
2017-07-09 04:56 user1958 Note Added: 0012067
2017-07-14 17:17 ludovic Note Added: 0012103
2017-07-18 19:59 user1958 Note Added: 0012115
2017-07-19 15:07 ludovic Changeset attached => sogo master 032b2fbb
2017-08-11 17:38 ludovic Status feedback => resolved
2017-08-11 17:38 ludovic Resolution reopened => fixed