How to avoid loss of data after editing a date sequence?

This was always going to be a contentious decision and I knew that a conversation like this would eventually happen.

This is why I added the ability to clone both a series and an instance. If new dates are added it would be simpler to clone the instances for the dates, or if there are to be quite a few extra dates, then clone into a new series.

This is also why there is that prompt at the top showing what changes are made and that the instances will be recreated. That is to avoid user error. It's a confirmation dialog and without clicking save a second time nothing happens

The problem is that it is nearly impossible to update instances if series data changes.

Let's look at a scenario:

A monthly event starting dec 1 to may 31, taking place on the first and third Wednesday of the month. People start registering for the event. And in January it is realized that the event needs to be changed to the Tuesdays and Thursdays due to demand. You have a load of Wednesday instances and now need to somehow figure out how to update those to match the new Tuesday and Thursday configuration. Add in the complications of excluded and included dates, and you cant just assume because some one registered for the Wednesday that they can go on a Tuesday.

Now not all changes will be that drastic. Some may just be start dates, but the complication is having to programmatically determine whether the change is a simple change or not, and if it is how do we update events and not force the hand of a registrant.

The other complication is the flexibility of recurring events allows for modification of the event instance independently of the series, so you can update a single date or time, or other information, without affecting the other instances. How do we programmatically determine how to update those instances and their registrations.

This was not a decision taken lightly and it has raised eyebrows a couple of times. Once events have taken registration, or especially payment, it feels right to lock those down and not let them be changed. But that shouldnt be an assumption that is made by the module, that should be a user training and implementation issue. If the module dictates that an event cannot be modifies once it is created, then there will be use cases where this becomes a problem. There will also be use cases where that is great.

It's tough to walk the fine line between being flexible and implementation agnostic, and making assumptions and decisions on behalf of sites using the module.

As always I'm a completely open to this being a conversation. I wanted to explain some of the "why" so that the conversation could be transparent.

Hey Owen. Today I duplicated this issue without realising. I think the best and simplest solution for the 'losing registrations' problem might be, if it's possible, to let the current edit event function do what it already does which is duplicate the event and adding the new edits then delete the old event but then copy all the registrations to the new event.

I put some UX/UI requests with good reasoning (IMO) in the other issue as well. Here it is:

A couple of suggestions for things to add that'll help the UX and stop confusion.

A "Cancel Changes" button. Yes you can simply cancel by navigating away from the page but a cancel button would be handy.

More importantly, it will be better if the Confirmation form is a pop up or modal so users don't miss it. At the moment the Confirmation form blends into the top of the Edit Event Series page and it's quite easy for any user to miss it and navigate away without saving their changes thinking they have because they clicked "Save" at the bottom of the page already and the jump to the top of the page gives the impression that changes were actually saved. If not a modal, have the Confirmation down the bottom of the page because it's just second nature to expect to finish (Save) things at the bottom of a page.

Adding cancel changes is a good idea. I'll get that done.

I think the best and simplest solution for the 'losing registrations' problem might be, if it's possible, to let the current edit event function do what it already does which is duplicate the event and adding the new edits then delete the old event but then copy all the registrations to the new event.

This here is the crux of the issue. Copying all registrants over to the new event(s) is really tricky, because how do you know how to map those registrants?

Scenario (similar to above).

An event recurs every Wednesday at 10am. People start registering for individual instances. The event series is then changed to occur instead on Tuesdays and Thursdays, due to demand. You have a bunch of Wednesday registrations - do you map those to the Tuesday events, or the Thursday events? What if there are fewer events, rather than more? There are so many different combinations and permutaitons of how the series recurrence data could change that figuring out how to "copy the registrations to the new event" becomes nearly impossible. If the event registration is for the entire series, then mapping could potentially be done (it is not done at this time). But for individual instance registration this becomes extremely difficult.

You would only automatically transfer existing registrations across to the new instances where only the event time/s has/have been edited without any extra instances added. If there are more instances added you could save all the registrant data and then send out notification/confirmation messages to all the registrants while reserving same number of spaces for them and let them choose which instances they would like to attend. And maybe put an RSVP time limit on it which would randomly allocate them to whichever new instance time is closest to the instance time in their original registration.

There would have to be a restriction or some kind of rule in place where event edits can't reduce spaces below the number of spaces that have been filled already. If the case of editing to reduce spaces is unavoidable then the event host/promoter can (issue refunds if required then) reduce the spaces available but there should be a stern and elaborate explanation of what they're about to lose (especially regarding registrations) by editing the event rather than just saying that the instances will be deleted.

The flexibility to change events is great but I don't think either side of the deal wants to have existing registrations deleted in any and every edit scenario for the sake of that event editing convenience.

I understand it's a complicated situation with many possible variables to change but the registration data needs to be saved somewhere so the registrants can be somehow notified of the event changes.

Adding cancel changes is a good idea. I'll get that done.

That'll be great but what about moving the Confirmation form to the bottom of the page under the 'Save' button or into a modal?

That'll be great but what about moving the Confirmation form to the bottom of the page or into a modal?

Sorry I meant to reply to that too. Yea I'll look at adding a modal for that. I'm worried that bottom of the page would get even more buried, given the page should refresh being at the top made the most sense at the time. Modal might make more sense.

You would only automatically transfer existing registrations across to the new instances where only the event time/s has/have been edited without any extra instances added.

This may be achievable but it may only affect a small minority of potential changes to the event series.

If there are more instances added you could save all the registrant data and then send out notification/confirmation messages to all the registrants while reserving same number of spaces for them and let them choose which instances they would like to attend. And maybe put an RSVP time limit on it which would randomly allocate them to whichever new instance time is closest to the instance time in their original registration.

Emails should be sent out when registrations are deleted. Reserving spaces with a time limit to re-register and allocate an event based on proximity to the deleted event starts getting very complicated all of a sudden. Is it worse to remove a registration (refund if necessary using the hooks provided by the module) and alert the user, or to move them to a completely random date/time? I get that losing a registration would be frustrating, but to be moved to some other time/day would be a really bad user experience in my opinion.

There would have to be a restriction or some kind of rule in place where event edits can't reduce spaces below the number of spaces that have been filled already. If the case of editing to reduce spaces is unavoidable then the event host/promoter can (issue refunds if required then) reduce the spaces available but there should be a stern and elaborate explanation of what they're about to lose (especially regarding registrations) by editing the event rather than just saying that the instances will be deleted.

Changing the number of spaces at this time does not affect any of the instances, the only thing that would is date changes. So if 10 people are registered and the capacity is reduced to 8, then nothing happens. 10 people are still registered and the admin would have to cancel/message those who can't come manually.

What I meant by fewer spaces, was more than fewer events are taking place, rather than a lower capacity. So if there are 10 weeks of wednesday events and people are registered across all ten weeks. Then because of maintenance, or something else, that event has to be cut short to only 8 weeks. What do you do with the people registered on weeks 9 and 10?

The flexibility to change events is great but I don't think either side of the deal wants to have existing registrations deleted in any and every edit scenario for the sake of that event editing convenience.

I understand it's a complicated situation with many possible variables to change but the registration data needs to be saved somewhere so the registrants can be somehow notified of the event changes.

Registrants are notified by email.

This is why its a very tricky line to walk and I'm willing to discuss and think of ideas to address it. This is super complicated, and gets even more complicated if we start looking into multiple registrants per registration. There quite simply is no simple or obvious solution.

And to reiterate: Event instances and registrations are ONLY deleted if the date recurrence changes, not anything else. You can modify any other setting without affecting the instances.

It this situation the Wednesday has been cancelled, so the registrations should be cancelled as well. If an organiser goes down this route they have only themselves to blame :)

I don't disagree with this. Technically from a code point of view i would have to loop through each new instance and compare those to existing instances to see if the old dates exist in the new structure, if they do not then I'd have to just delete those instances and registrants. I imagine this may be complex to determine but it may be possible. I'll investigate.

If the number of instances is increased, whether at the beginning, the end or in the middle, existing registrations should be preserved. Put another way; additional instances get inserted into the existing series.

Again I'd have to do some comparisons with existing instances to see if dates were added at the beginning/end - but would also need to determine if dates were added in the middle too - like a wednesday date added to a tuesday/thursday weekly event.

If the instances in a series are reduced, any registrations for cancelled instances should also be cancelled. It would be up to the organiser advise registrants what was going to happen and rebook them (manually perhaps) for another instance of their choice.

Again, lots of comparisons to see if the event instance used to exist and does not any more.

Consider this example; A performance has sold out for the Friday night so the organiser puts on a extra date for the Saturday. The organiser, would not cancel every ticket and invite them to rebook for their preferred night. What would happen, is seeing that Friday was sold out, new registrants would book for the Saturday.

In this event, cloning is the perfect solution. Rather than edit the whole series, just clone a new event instance on to the end of it. I would definitely not recommend updating the series recurrence configuration to just add a new event at the end. But do need somehow to protect against it breaking things.

Lots to ponder. Good ideas coming through and still some difficulties and complexities to iron out. I know for example that Google Calendar works similarly to RE in the sense that events get wiped out and re-added if you update how the event recurs, but when purchasing tickets etc is concerned that becomes less viable.

Complementary to this issue, if #3468521: When changing recurrance, identical date combinations should not be deleted & recreated. lands the surface area for losing data after editing a date sequence reduces greatly (for example it handles the situation, excellently put by mrpauldriver, of adding a performance to a sold-out series).