[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         | lst_hoe02 at kwsoft.de
  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
------------------------------------------------------------------------------


lst_hoe02 at kwsoft.de (2009-03-25 08:53) wrote:

The problem is more general than just Sunbird. As far as i can see  
there is no way in RFC2445 to say the ALARM is already  
accepted/cleared. So if you have more than one client to the same  
calendar you always bounce the ALARM if the clients treat clearing of  
the ALARM as change (as most clients seam to do). So basically the  
client sent the ALARM reset with whatever method it thinks is useful  
to the server and the server mark the events as changed without a  
possibility to fool-proof detect that the change is reset of the  
ALARM. With this the second client get this events as changed and the  
ALARM set so it is fired again on the second client.
Maybe the best way would be to unconditionally delete the ALARM when  
it is in the past when we import to Kronolith??