Tickets :: Comment on [#12984] Dismissed Alarms coming back / still popping up on Mozilla Lightning

Search Results: 81 of 250 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: . .. ..___.__ ._. \|\ \|\| \|[__ [ __ \| \| \\|\|/\\|[___[_./_\|_
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.
Attachment
Watch this ticket

Saved Queries