By updating a series, it deletes all the eventinstances and recreates them, which deletes all information stored on the instance.

Thank you for raising the issue, unfortunately this is a known by-product of having series and instance entities as separate entities. If the recurrence structure changes, the editor should be warned and have to accept that instances will be removed. This is far from ideal, but the coding required to figure out whether or not to remove instances, or add instances, or switch instance dates around etc is really quite complicated. There are lots of different scenarios to factor in, and handling this programmatically is not a simple task. For example: Has just the time changed? Has the duration changed? Has the start/end date changed? Is there an easy way to map particular instances to their new date and times? What about deleted events? What about added events? This is why there is the warning when changing the pattern of recurrence or the date/time.

If anyone has the desire and time to want to tackle this problem then I'm all on board, it is a known shortcoming but I can't see an easy out.

Can we, upon validating any change, check the all dates, and for any of them are unchanged [start/end] by the new "recurrence structure" , can we update by id rather than create a new instance? then still deleting anything that doesn't match.

I like this idea because, for example, my client often just wants to add new instances to an event series without altering the old ones at all. For example, a weekly event that runs from Aug 1 to Aug 30 and they decide to extend to Sept 30. They would just want 4 new events added and don't need the old ones to change at all.

I understand this would still be complex though. Plus with registration enabled, there are those elements to consider. If "Entire Series Registration" was enabled and 4 new dates are added, should all the registrations also carry over? Should an automatic notification be sent if so?

I have opened an MR which creates the foundations to be able to do some more interesting things as far as creating event instances. I created a plugin manager, and a default plugin, which are executed when there are date changes to an event series. The default plugin does the same thing that has always existed with the module - it removes and recreates all the event instances. It is therefore called the recurring_events_eventinstance_recreator.

Now moving forward, different plugins could be written (and selected in the event series settings form) to do differnt things, for example, one could be created to achieve the desired functionality of this issue, and we do not need to modify the default functionality or hack away at it at all.

So, in order to attempt to determine whether event instances need to be recreated, or merely updated, a new EventInstanceCreator plugin can be written to do so. That task is a bigger, more difficult task to achieve and I have not yet started any of it, but this MR should at least set the stage for writing something that could do that as a plugin.

I've merged the MR to add the ability to create plugins to control how instances are recreated, but the underlying issue of not deleting instances has not been resolved as it quite frankly is a very tricky issue.

There are lots of considerations to make:

1. When should a date/time be updated vs recreated.
2. How do we determine the 'nearest' date/time to move to?
3. What do we do with registrants for an event which now gets updated to a different date/time?

So for now, I'll leave this issue open, but the MR to support someone creating this functionality has been merged.

Thank you very much @owenbush for the work. I'm going to try to take a look at things. Is it possible that the easiest place to start would be either:
- every event instance remains exactly the same except a new one is added (same exact time and following same recurrence pattern)
or
- every event instance remains exactly the same except a single one is removed

In other words, in these cases, the existing event instances would not change at all. There would either be a single new event instance added or a single event instance removed. (I know currently this is possible via cloning an event instance and just deleting one event instance). Maybe this could be a trial run for a new plugin to see how complicated it gets?

On adding a new event instance, any "event series registration" rules would need to be followed. Any other complications foreseen?

On removing one instance, the regular event removal emails should be sent. Any other complications foreseen?

For what it's worth, for my client, a lot of the changes they make are for one-off events using "Custom/Single Event" recurrence type. This is a major pain point for them because they can't easily change the date/time for just a single event without risking losing all registrants.

There are certainly opportunities around events that only adding/removing instances I just haven't had a chance to really explore that much.

But I wanted to reply to

This is a major pain point for them because they can't easily change the date/time for just a single event without risking losing all registrants.

You should be able to modify individual instance dates without doing it through the series. If you edit the instance itself, the date/time feels are editable.

You should be able to modify individual instance dates without doing it through the series. If you edit the instance itself, the date/time feels are editable.

It is possible, but it doesn't update any of the views using Event Series. So, for example, when the client uses the admin Events listing page, the Event Series show their original date and time and not the date and time from the Event Instance. This has been very confusing for the client as they believe their changes were not saved.

Ignore the last commit, I was getting 8.x-1.x in sync with 2.0.x

There are in the meantime newer issues that aim to implement different method of creating event instances.

Maybe now that the ground work is done we can close this issue and leave the implementation of different EventInstanceCreator plugins to followup issues?

It looks like the discussion that has been had here are now use cases that are solvable in dedicated issues.

• We can have an issue to make it possible to choose which plugin to use for an event series.
• A plugin that attempts to preserve event instances for as long as the start and end dates are unchanged: #3468521: When changing recurrance, identical date combinations should not be deleted & recreated.
• A plugin that refuses to make any changes to existing event instances: #3479449: Provide a 'NoOperationEventInstanceCreator' that prevents event instances from changing when event series is saved
• A plugin that will move existing event instances to the nearest neighbor.

I am going to go ahead and close it, please feel free to reopen if you want to keep discussing possibilities here.

@pfrenssen Thanks for adding those. This is something I've run into with any recurring date feature, when you set up a bunch of event instances and want to be able to determine whether to keep existing ones and how to adjust them. I would really like to see something like an event management API that is also compatible with Smart Date and Recurring Dates Field.