[Tickets #7470] Re: Sunbird/Lightning alarm dismissal and snooze incompletely implemented

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/7470
------------------------------------------------------------------------------
  Ticket             | 7470
  Updated By         | spamstop1 at terriertech.com
  Summary            | Sunbird/Lightning alarm dismissal and snooze
                     | incompletely implemented
  Queue              | Kronolith
  Version            | 2.3
  Type               | Enhancement
  State              | No Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Horde Developers
+New Attachment     | Snooze.patch
------------------------------------------------------------------------------


spamstop1 at terriertech.com (2011-04-29 20:46) wrote:

> That should work as long as the client supports *any* way of sending  
> snooze information in iCalendar.

It works to prevent continual alarms.  But if the event recurs,  
deleting the alarm also prevents it from firing for future recurrences  
of the event.

I could not see a good solution without storing the snooze info with  
the event.  Therefore, I added an event_snooze varchar column to  
kronolith_events.  See attached patch (relative to 3.0.2-git).

This seems to work for dismiss, snooze (including multiple successive  
snoozes, in limited testing), and recurring events (if the LASTACK  
occurs before one occurrence, then Thunderbird views the following  
occurrence as not ACKed).  It also seems to work OK on multiple  
Thunderbird clients in the same timezone, i.e. snoozing on one client  
will auto-dismiss the alarm on other clients next time they reload the  
calendar.

Hope this helps.

PS: I know this has been dormant for a while, but it is no less of an issue.