[Tickets #12984] Dismissed Alarms coming back / still poping up on Mozilla Lightning

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12984
------------------------------------------------------------------------------
  Ticket             | 12984
  Created By         | sberthelot at emisfr.com
  Summary            | Dismissed Alarms coming back / still poping up on
                     | Mozilla Lightning
  Queue              | Kronolith
  Version            | 4.1.4
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


sberthelot at emisfr.com (2014-02-20 10:26) wrote:

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.



sberthelot at emisfr.com (2014-02-20 10:26) uploaded:  
kronolith-event-dismiss.diff

http://bugs.horde.org/h/services/download/?app=whups&actionID=download_file&file=kronolith-event-dismiss.diff&ticket=12984&fn=%2Fkronolith-event-dismiss.diff