GNOME Bugzilla – Bug 324219
Recurrence Appointment is stripped to current month when moving to another calendar
Last modified: 2021-05-19 12:12:48 UTC
Distribution/Version: Ubuntu 5.10 1. Create an Appointment with recurrence options to at least a date in the next month (here: Every 1 weeks until 09/02/2006). (2. Create a new Calendar or use an existing one) 3. Open the Appointment and choose the other calendar on 'Calendar:' 4. Click 'OK' 5. Open the Appointment again The Recurrence Option is now: Every 1 weeks until 29/12/2005 With Evolution 2.2.x it works as expected.
*** Bug 324263 has been marked as a duplicate of this bug. ***
*** Bug 324270 has been marked as a duplicate of this bug. ***
adding dependency to recurrences tracker bug
I have investigated this and I think the problem is that moving the event moves one occurence of it, not the original event. You can verify that by looking at the copy in the calendar.ics file: most likely it'll have a "RECURRENCE-ID". The effect then is that the recurrence rule is ignored by the code in libecal which generates all instances of the event, because the event already _is_ an instance. I won't investigate further where and how the "move to calendar" code is broken, because my own problem is with recurrences in my Exchange calendar, which now seems unrelated (still need to create a bug entry for that, though).
The RECURRENCE-ID is also added when saving the recurring event into an .ics file. This means that importing it again suffers from the same problems as if it had been moved between calendars. Probably caused by the same code, I just thought I should mention it... For sake of completeness, I tried this with Evolution 2.6.3, compiled from source with garnome 2.14.3.
Created attachment 107730 [details] [review] proposed evo patch for evolution; When saving recurring event to other than initial source, then take care to either split it correctly or move the master object too.
I see a lot of issues related to recurrence handling since its ambiguous to choose an instance or all instances (master object). It would be better if we ask the user, whether he wants to open the instance or the series. Once thats done, we can move the right object to the destination calendar. This would help us clean a lot of unwanted code in evolution as well as EDS. We would also need to handle the case if the user wants to move both the master object and all detached instances.
Chen, watching the place of change, and noticing the fact of using priv->mode, I believe the user had been asked whether to move the instance only or the all object with instances already. This all is done as part of a comp editor saving, isn't it?
ping chen
Yes for the editor. I dropped the plan for asking the user for asking the user while opening the event. And instead used comp_util_sanitize_recurrence_master to sink the changes to master event. + /* transfer master object first and then modify it */ This would create two network calls.. Just thought about another case. I think we need to take care of updated uid in e_cal_create_object. Some backend's may change the uid when creating events on the server. Please provide a updated patch considering these..
I'm afraid I do not understand. Please kick me on IRC, thanks.
Created attachment 139887 [details] under construction beh, as discussed on IRC, we should call e_cal_create_object as many times as is count of detached instances for the event, which backend returns properly in get_object, but e_cal_get_object extracts the first component for VCALENDAR components returned from a backend, thus those are lost quite quickly. Chen suggested to ad a new API function e_cal_get_object_full (or some similar name), which will not strip the object. In that case this patch should be slightly improved (and removed debug prints from there). Because of all the upcomming changes, let's wait for a while with this, after things settle.
*** Bug 648759 has been marked as a duplicate of this bug. ***
Milan: Planning to pick up your patch again? If not, can you change the status to NEW?
Moving to NEW, I'm currently on slightly different set of bugs. I'll revisit later, hopefully.
Assuming this is still valid as per comment 14 and comment 15.
Fidencio is dealing with this within bug #657808
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.