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

[noreply at bugs.horde.org]

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

Ticket URL: https://bugs.horde.org/ticket/12984
------------------------------------------------------------------------------
  Ticket             | 12984
  Updated By         | alexander_couto at yahoo.com.br
  Summary            | Dismissed Alarms coming back / still popping up on
                     | Mozilla Lightning
  Queue              | Kronolith
  Version            | 4.1.4
  Type               | Bug
  State              | Assigned
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             | Jan Schneider
------------------------------------------------------------------------------


alexander_couto at yahoo.com.br (2020-09-02 19:24) 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.