|Anonymous | Login | Signup for a new account||2017-08-19 03:22 EDT|
|My View | View Issues | Change Log | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002561||SOGo||Web Calendar||public||2013-12-19 08:59||2017-08-11 13:38|
|Target Version||Fixed in Version|
|Summary||0002561: Can not invite to an exeption only|
|Description||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!
|Tags||No tags attached.|
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 (developer)
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.|
sogo: master 032b2fbb
Timestamp: 2017-07-19 11:05:16
|(fix) can now invite to exceptions only (fixes 0002561)|
|mod - NEWS|
|mod - SoObjects/Appointments/NSArray+Appointments.h|
|mod - SoObjects/Appointments/NSArray+Appointments.m|
|mod - SoObjects/Appointments/SOGoAppointmentFolder.m|
|mod - SoObjects/Appointments/SOGoAppointmentObject.m|
|mod - SoObjects/Appointments/SOGoCalendarComponent.m|
|mod - SoObjects/Appointments/iCalCalendar+SOGo.h|
|mod - SoObjects/Appointments/iCalCalendar+SOGo.m|
|mod - SoObjects/Appointments/iCalEvent+SOGo.m|
|mod - UI/Scheduler/UIxCalListingActions.m|
|2013-12-19 08:59||Christian Mack||New Issue|
|2014-02-07 07:36||ludovic||Note Added: 0006519|
|2014-02-07 07:36||ludovic||Status||new => closed|
|2014-02-07 07:36||ludovic||Assigned To||=> ludovic|
|2014-02-07 07:36||ludovic||Resolution||open => won't fix|
|2014-02-28 04:40||Christian Mack||Note Added: 0006584|
|2014-02-28 04:40||Christian Mack||Status||closed => feedback|
|2014-02-28 04:40||Christian Mack||Resolution||won't fix => reopened|
|2014-05-22 06:09||Marcel||Note Added: 0007062|
|2014-06-08 11:14||Marcel||Note Added: 0007158|
|2014-11-05 03:35||Christian Mack||Relationship added||has duplicate 0002977|
|2015-10-04 05:56||thomas||Note Added: 0008972|
|2015-10-04 06:10||thomas||Note Added: 0008973|
|2016-11-23 15:23||francis||Relationship added||has duplicate 0003911|
|2016-12-28 10:56||ludovic||Relationship added||related to 0002427|
|2016-12-29 13:10||ludovic||Relationship added||related to 0003882|
|2017-04-11 12:04||ludovic||Relationship added||has duplicate 0004144|
|2017-05-29 10:57||teryx||Note Added: 0011842|
|2017-06-16 11:30||ludovic||Relationship added||related to 0004068|
|2017-07-09 00:56||mrcoollv||Note Added: 0012067|
|2017-07-14 13:17||ludovic||Note Added: 0012103|
|2017-07-18 15:59||mrcoollv||Note Added: 0012115|
|2017-07-19 11:07||ludovic||Changeset attached||=> sogo master 032b2fbb|
|2017-08-11 13:38||ludovic||Status||feedback => resolved|
|2017-08-11 13:38||ludovic||Resolution||reopened => fixed|
|Copyright © 2000 - 2017 MantisBT Team|