GNOME Bugzilla – Bug 544813
Allow recurrence editing for non-detached instances
Last modified: 2015-09-21 13:44:01 UTC
the bug has been opened on https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/251995 "Create a new Friday appointment that recurs weekly, forever. Go back in and change the recurrence from Friday to Saturday. Click "Save" on the appointment, and it'll ask if you want to save it for "This Instance Only" or "All Instances". Alright, this is the first problem. It makes no sense to edit the occurrence for a single instance. Select "This Instance Only", and save it. Now, when you go back in, the recurrence information is grayed out, and you can't change it. This is true of both the instance you changed or any other instance. You can see that the instance you changed has no recurrence info, but all others have the original recurrence info. But you can't change any of them. Also, nothing actually changes day. Not even the one you told to. You can regain access to the recurrence settings by changing the time for all appointments. But the state of the series never seems quite right again, and it seems to lead to cascading badness, possibly including crashes. This was produced using a local calendar."
reproducible in 2.29.1, see bug 589344 also
(In reply to comment #0) > Alright, this is the first problem. It makes no sense to edit the occurrence > for a single instance. There is not created any diff what user actually changed, thus Evolution always asks whether modify all or only this instance. Other applications ask before the editing dialog is shown, which makes sense too. With respect of the behaviour, I believe it's correct. When you do changes in your recurring event, and choose only this instance, then the instance became a detached instance, which means it's sort of an exception to the (master) recurring event. The recurring rule in a detached instance has no sense, as it's this instance only. Furthermore, I noticed a discussion about the similar behaviour with respect of creating event time and recurring rule, and if I recall correctly the result was that Evolution is behaving like it should, based on the RFC too, which means that the first occurrence of the recurring event is always in the time of its creation, and all the others are set by the recurrence rule. Thus I do not see any issue with Evolution. With respect of not able to change a recurrence rule after creating a detached instance, I can reproduce it too. That might be a problem. Chen?
I agree with the first case, while modifying the rrule of a recurring event one would not intend to make changes to an instance alone as a detached instance will not have a rrule. This holds good unless we support changing, 'This and prior' or 'This and future'. With the second issue, while modifying an detached instance the recurrence settings will not be available and so will be disabled. detached instances will not have the rrule information in them. Maybe better to provide a visual cue that its a detached instance and so recurring settings wont be available?
(In reply to comment #3) > With the second issue, while modifying an detached instance the recurrence > settings will not be available and so will be disabled. detached instances will > not have the rrule information in them. Maybe better to provide a visual cue > that its a detached instance and so recurring settings wont be available? Oops, maybe not understood by the comment, but I wasn't modifying that new detached instance, but some other instance, which was part of the master object, aka other occurrence than the one I change with "This instance only". The recurrence options are disabled on those.
Yes I see it too. its a bug.
Still there on actual master (~2.30.0). To summarize: editing of a recurrence should be doable on an event which is not a detached event.
*** Bug 754355 has been marked as a duplicate of this bug. ***
Is it possible to fix this bug after so many years?
Created attachment 311333 [details] [review] evo patch for evolution; So the detached instances do not have RRULE, while the instances generated from the master object does. Count with it and enable the recurrence editor based on it.
Created commit c6c2647 in evo master (3.19.1+) Created commit f24533a in evo gnome-3-18 (3.18.1+)