After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 558634 - Changing date of recurring appt/mtg gets double mtgs, removes earlier
Changing date of recurring appt/mtg gets double mtgs, removes earlier
Status: RESOLVED NOTABUG
Product: evolution
Classification: Applications
Component: Calendar
2.30.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[compeditor]
Depends on:
Blocks:
 
 
Reported: 2008-10-31 06:15 UTC by bill
Modified: 2017-08-28 16:32 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28



Description bill 2008-10-31 06:15:06 UTC
Please describe the problem:
If you change the date of a recurring appointment or meeting, you get appointments/meetings on both days, plus you delete all earlier instances of the appt/mtg.

Steps to reproduce:
(1) Create a new weekly appointment.
(2) Open the 3rd instance of the appointment.
(3) Change the date to the previous day.
(4) Click "Save"
(5) When prompted, click "All Instances", then "OK"

Actual results:
(1) The mtgs/appts from the first 2 weeks are completely gone.
(2) From the 3rd week forward, there are now mtgs/appts on both days.

Expected results:
(1) Earlier meetings should not be deleted. They should either remain where they were, or move by the same amount as the later appointments.
(2) Each week should have only one meeting, on the new day.

Does this happen every time?
Happens every time.

Other information:
This is Ubuntu bug 252003 - https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/252003
Comment 1 Akhil Laddha 2008-11-03 07:54:39 UTC
which provider ?  Have you tried with current stable 2.24.1 ?
Comment 2 Akhil Laddha 2009-09-04 10:32:02 UTC
valid in 2.27.91
Comment 3 Milan Crha 2010-03-26 14:01:11 UTC
I can reproduce this on actual master (~2.30.0) too, with a local backend (On This Computer). When I edit the newly created event, then I see it has checked both days in the recurrence. Anyway, it forgets the old instances, which is wrong. There was (maybe still is) opened a bug report about "Ask for 'This instance'/'All instances' before editing", which might fix this pretty well, because in that case will be used the proper master object, not the one which is moved by 3 occurrences. but Chen changed his mind on that bug, if I recall correctly.
Comment 4 Milan Crha 2017-08-28 16:32:02 UTC
I've been wrong, the way evolution behaves is correct. The "All Instances" means really all instances (except of detached instances), thus to redefine the whole meeting recurrence, thus it makes sense that past instances are changed as well (removed, in this case).

(In reply to bill from comment #0)
> Expected results:
> (1) Earlier meetings should not be deleted. They should either remain where
> they were, or move by the same amount as the later appointments.

They "moved" for me, because I had the recurrence set "for 5 occurrences". They still repeated on Monday, even I moved the third instance to Sunday, but it's also expected, because I didn't touch the recurrence rule.

> (2) Each week should have only one meeting, on the new day.

Recurrence is defined (in RFC) as the master object's start/end, then this start/end being modified with the recurrence rule. Thus the event is usually visible on the day it had been set to and then where the recurrence rule "moves" it. The start day can be removed with an exception date.

Nonetheless, I agree the behaviour is confusing. I think that's one reason why the latest RFC 5545 defines to not use more than one RRULE and deprecated EXRULE, with which one could define pretty complex recurrences, but they could be hard to follow.