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

Search Results: 16 of 94 [ <<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