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.

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.

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?

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?

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...

...2.3.2 of course.

Is there any progress regarding this issue ?

As you stated in 0004144 (https://sogo.nu/bugs/view.php?id=4144#c11706) you did this by design to handle limitations in caldav clients. But you also mentioned that these limits are gone now.

Any update ?

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

ok thanks