Moving a recurring time-based event "and all subsequent events" via drag-and-drop causes duplication and non-existent events in the backend
This is the new form of issue #87 (closed), but for time-based events only, as all-day recurring events seem to work OK. Related in testing to #951, #870 and #178 (closed).
My previous issue #87 (closed)'s original description was pretty vague:
When changing the calendar a recurring event is assigned to, it seems gnome-calendar just creates a local duplication of the event instead of reassigning all occurrences of the existing event to the newly chosen calendar, which creates a big mess...
...but it remains the simplest way to describe it. The only thing to add is that nowadays, this only affects time-based events.
Here is a video demonstration with GNOME Calendar 46 and Evolution/EDS 3.50.4: https://youtu.be/LQjZpseJKB8
Reproduction instructions
- Create a time-based event (ex: from 14h to 15h) in Evolution that repeats daily for three days
(creating it in Evolution at least ensures we are creating the event correctly in a way that EDS likes it) - Using GNOME Calendar, drag-and-drop that event to some other day in the month view, and when prompted, choose to shift all subsquent events
Observed results
- Lots of duplicates, and...
- When you create those duplicates, it gets to a point where the backend breaks badly enough that even Evolution can't delete those events, as they are "non-existent", as shown with the error infobar in the demonstration video above.
I don't know how it is technically possible that Evolution 3.50.4 can display them if they "don't exist" in the backend, but @mcrha might have an idea about that. Those events only disappear from Evolution's view after restarting the app. Maybe we are simultaneously hitting a GNOME Calendar and EDS/Evolution bug, somehow?