GNOME Bugzilla – Bug 261625
Extending old event causes new alarm to fire
Last modified: 2013-09-10 14:03:47 UTC
Description of Problem: If you modify an old event that has passed (for instance, extending a meeting duration to account for a meeting that ran longer than it was supposed to), a new alarm fires for that event, even if you modify it to have occurred in the past from your present time. I would not expect a new event to fire unless the change crossed the current time or was in the immediate future within the alarm window. I guess you would also have to consider a post-event alarm that was set that would span the current time as well. Steps to reproduce the problem: 1. Create an event earlier in the day with an alarm 2. Modify the event to be longer than it was (or shorter I suppose) but not to extend to the current time 3. An alarm should fire Actual Results: An alarm for the event fires Expected Results: The alarm should not fire as the alram previously fired and the event (and all its alarms) are in the past. How often does this happen? Every time.
Can see this in evo-2.4 Even creating a event in past does the same ... Assiging to myself.
*** Bug 267391 has been marked as a duplicate of this bug. ***
Only creating new event in past fires an alarm in evo 2.4. The original report of firing alarm when time of a past (alarm-fired) event is not to be seen in evo 2.4. Attached a patch to fix this problem.
Created attachment 51949 [details] [review] checks if alarm trigger time is after current time An if statement that checks if the alarm trigger time is after the current time before adding the alarm to the queue and setting up a timeout.
Now it would not popup any alarms for the events that has passed away. But as we discussed earlier, we need to show them too, indicating that the meeting has been missed.
Fix has been committed for gnome-2-12 and head.