[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         | mail at mail.spreech.de
  Summary            | Sunbird/Lightning alarm dismissal and snooze
                     | incompletely implemented
  Queue              | Kronolith
  Version            | 2.3
  Type               | Enhancement
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             | Horde Developers
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2009-01-29 06:31) wrote:

> can you clarify the situation where the Driver patch breaks?

Horde_Alarm has been added with Horde 3.2. But we maintain backward  
compatibility in all H3 applications with any Horde 3.x version, i.e.  
also with Horde versions before 3.2. Thus you can't simply assume that  
Horde_Alarm exists in Kronolith code.
Beside that, since I implemented the iCalendar patch differently, the  
Kronolith patch has to be updated to reflect that.

> It seems to me if you are subscribed read-write to a calendar and
> then add an alarm in the external application that it should
> overwrite any alarm in the database for that event.  In addition, if
> you remove an alarm it should remove it from the database.

Exactly, and this already happens, e.g. in  
Kronolith_Driver_sql::deleteEvent(). You can use the Horde_Alarm  
handling there as a blueprint for your own changes in the snoozing code.

> The situation where one is subscribed to the calendar via ics,
> perhaps in Sunbird, and the calendar is updated in kronolith and then
> sent from Sunbird prior to downloading changes from kronolith is one
> that is impossible to handle with the current version of Sunbird
> because it doesn't have any sense of an offline cache or validation
> of changes over webdav.  Whoever writes last always wins in that
> scenario.

Yes, but that has nothing to do with this request anyway.