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

* Your Email Address
* Spam protection	Enter the letters below: __..___..___..__ __ (__ \| \| \| \/ ` .__) \| \| \|__/\__.
Comment	> 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??
Attachment
Watch this ticket