Scalable OGo (SOGo)

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002561SOGoWeb Calendarpublic2013-12-19 08:592017-08-11 13:38
ReporterChristian Mack 
Assigned Toludovic 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version2.1.1b 
Target VersionFixed in Version 
Summary0002561: Can not invite to an exeption only
DescriptionYou 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 Reproduce1) 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.
Attached Files

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

-  Notes
User avatar (0006519)
ludovic (administrator)
2014-02-07 07:36

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.
User avatar (0006584)
Christian Mack (developer)
2014-02-28 04:40

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.
(0007062)
Marcel (reporter)
2014-05-22 06:09

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?
(0007158)
Marcel (reporter)
2014-06-08 11:14

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?
(0008972)
thomas (reporter)
2015-10-04 05:56

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...
(0008973)
thomas (reporter)
2015-10-04 06:10

...2.3.2 of course.
(0011842)
teryx (reporter)
2017-05-29 10:57

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.
(0012067)
user1958
2017-07-09 00:56

Any update ?
User avatar (0012103)
ludovic (administrator)
2017-07-14 13:17

Code has started and excellent progress was made this week. Except a commit early next week.
(0012115)
user1958
2017-07-18 15:59

ok thanks

- Related Changesets
sogo: master 032b2fbb
Timestamp: 2017-07-19 11:05:16
Author: ludovic
Details ] Diff ]
(fix) can now invite to exceptions only (fixes 0002561)
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 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-07-09 00:56 user1958 Note Added: 0012067
2017-07-14 13:17 ludovic Note Added: 0012103
2017-07-18 15:59 user1958 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
Powered by Mantis Bugtracker