757458 - Propagate attendees changes to the event exceptions

Status: NEW

(Calendar :: Dialogs, defect)

Description

[Laurent Jouanneau]

STEPS TO REPRODUCE:
===================

- create a recurrent event. save.
- change one of the occurrence (with a different start hour for example). save.
- edit the first occurrence, choice "edit all occurences", and add an attendee. save.
- open the exception 


RESULT:
=======
- the attendee is not shown in the exception

EXPECTED RESULT:
================
- the attendee should be shown in the exception.

Comment 1

[Laurent Jouanneau]

Attachment: The patch, v1

Here a patch, made originally by the OBM team.

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 626026 [details] [diff] [review]
The patch, v1

Review of attachment 626026 [details] [diff] [review]:
-----------------------------------------------------------------

Hmm, similar to the other bug, I'm not quite sure this is the right road to go. The more minor problem is that this attendee change propagation happens within the event dialog. We should be consistent, in case for some reason the attendee is changed from somewhere else.

The other problem I see is that some attendee changes could possibly not be wanted. What about this case:


* Organizer creates event with Joe, Bob and Mike.
* Organizer creates an exception where Bob is not needed and removes Bob from the attendee list
* Organizer makes a change to the description of the master event

Result with this patch:

* Bob is re-added to the attendee list of the exception.


I understand this might be how OBM works, but of course we need a solution that works for all providers. To solve this, here a few alternatives:

* Check if we can have this propagation happen in the storage provider and hide it beind a property like propagate.attendeesToException

* If you can point me to somewhere in the rfc5545 spec that says that this needs to happen, move the code to somewhere where it can be used generally and make sure all callers do so.

* Another Option would be to add UI that allows the user to decide if the changes should be propagated to exceptions. This could be a bit tricky though, since you'd need to give the user the option to do this for all exceptions or only specific exceptions. Also, for the OBM case this would still require a way for the provider to circumvent it and always make the propagation happen.

r- to address these comments.