6.0.0-git
2018-12-16

[#12984] Dismissed Alarms coming back / still popping up on Mozilla Lightning
Summary Dismissed Alarms coming back / still popping up on Mozilla Lightning
Queue Kronolith
Queue Version 4.1.4
Type Bug
State Assigned
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester sberthelot (at) emisfr (dot) com
Created 2014-02-20 (1760 days ago)
Due
Updated 2016-01-25 (1056 days ago)
Assigned 2016-01-25 (1056 days ago)
Resolved
Milestone
Patch Yes

History
2016-01-25 17:40:50 Jan Schneider State ⇒ Assigned
 
2015-05-28 06:34:37 grupodecorreo10 (at) gmail (dot) com Comment #8 Reply to this comment

[Show Quoted Text - 10 lines]
Good Morning, how can i not garbage-collect alarms that have been 
dismissed? I have the same problem and i want to fix it. Alarms 
dissapear if i uncheck "separate calendars" but only until next reboot.
2015-02-05 15:18:41 Michael Rubinsky Summary ⇒ Dismissed Alarms coming back / still popping up on Mozilla Lightning
 
2014-12-08 14:27:12 marth (at) tsvschlieben (dot) de Comment #7 Reply to this comment
Any further votes?
+1 For the second solution as well.
+ 1 For the second solution
2014-06-16 14:48:29 Michael Rubinsky Comment #6 Reply to this comment
Any further votes?
+1 For the second solution as well.

2014-06-16 14:38:18 Jan Schneider Comment #5 Reply to this comment

[Show Quoted Text - 12 lines]
Any further votes?
2014-05-27 16:10:39 lst_hoe02 (at) kwsoft (dot) de Comment #4 Reply to this comment
I'm not sure if it is the best solution to consider all past alarms 
as dismissed, though it's definitely one solution.
Alternatively we could not garbage-collect alarms that have been 
dismissed, though these alarms will stay in the database forever, or 
at least until the connected event/task is deleted.
I would vote for the second solution. Let the alarms stay in the db as 
long as the event is there. If one does not purge the events the 
additional alarms shouldn't matter, no? But i'm not sure how would 
this handle never ending recurrent events,  do they pile up in the 
alarm table "forever"?

2014-05-27 14:44:07 Jan Schneider Comment #3
State ⇒ Feedback
Reply to this comment
I'm not sure if it is the best solution to consider all past alarms as 
dismissed, though it's definitely one solution.
Alternatively we could not garbage-collect alarms that have been 
dismissed, though these alarms will stay in the database forever, or 
at least until the connected event/task is deleted.
A third option would be to don't change anything, because there is a 
setting in Lightning to not run missed alarms. As this option exists, 
I don't think the first solution is a good idea, because it renders 
this option useless. People would never get missed alarms even if the 
explicitly ask for it.
2014-03-21 12:28:15 Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
 
2014-03-14 20:02:13 thias (at) baerenhor (dot) de Comment #2 Reply to this comment
seems like a dup of #7470
2014-02-20 10:26:41 sberthelot (at) emisfr (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Dismissed Alarms coming back / still poping up on Mozilla Lightning
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ Yes
New Attachment: kronolith-event-dismiss.diff Download
Reply to this comment
I am using horde webmail 5.1.3 with kronolith 4.1.4.
When using iCal (ICS) remote subscription on Mozilla Thunderbird 24.3 
+ Lightning 2.6.4 I keep getting random reset on previous events 
alarms status. Then all alarms from about a month back are popping up 
again.

I have investigated into the code and attached a proposed patch.
To me the problem is twofold :
- Lightning make expired alarms pop up (all dismissed alarms popping 
up are always on old events)
- Kronolith randomly "garbage collect" old events alarms and then 
doesn't keep their status

Looking at the code it randomly purges the horde_alarm table ("gc" 
function) then all informations about old alarms are lost.
When exporting again the iCal in Event class the X-MOZ-LASTACK flag is 
not for old events set since we have no more entries for them in 
horde_alarm table.
Thus Lightning considers alarms as "fresh" for old events and make 
them pop up again...

So here is a patch attached that adds X-MOZ-LASTACK for all old alarms 
even if there is no more entry in horde_alarm table to keep the 
dimissed/snooze status.
This seems to be a workaround to me since I do not understand why 
expired alarms should me notified ... (Lightning actual behavior)

Moreover, to help with broken alarm dismissal client implementations 
(or read-only access trying to update alarm status info) it may be 
helpful to add a config/pref to Kronolith in order to remove expired 
alarms for iCal export. Since iCal cannot store the status of alarm 
notification (to my knowledge after reading the RFC, that's why 
Mozilla seem to have added an extension for this) I don't see any 
other mean to get rid of past notifications.
Either way, another subscription URL or better a query string (<ics 
url>?no_expired_alarms=1) could make it configurable by the subscriber 
for each client.

Saved Queries