See ticket #12984

Same problem here. Kronolith v4.1.2, Thunderbird v24.0, Lightning v2.6
(Ubuntu, Linux)

Same problem here. Kronolith 3.0.16, Thunderbird 11.0.1, Lightning 1.3 
(Ubuntu, Linux)

Is this still working for you? Alarmed events will pop up again and 
again in Lightning. Dismissing events won't work for me, they pop up 
some time later.  Can somebody reproduce this with the most current 
version of horde/kronolith and thunderbird/lightning?

Changes have been made in CVS for this ticket:

MFG 1eaf3dfe109fc7d9d8c858d83d0832861d799386, 
7968ea021de356d10580c02ff3be54038c98b17e:
Import VALARM components from iCalendar 2.0 data (Request #6665).
Support snoozing alarms with Sundbird/Lightning (Request #7470).
http://cvs.horde.org/diff.php/framework/Alarm/Alarm.php?rt=horde&r1=1.40.2.6&r2=1.40.2.7&ty=u
http://cvs.horde.org/diff.php/framework/Alarm/Alarm/sql.php?rt=horde&r1=1.11.2.13&r2=1.11.2.14&ty=u
http://cvs.horde.org/diff.php/kronolith/docs/CHANGES?rt=horde&r1=1.165.2.299&r2=1.165.2.300&ty=u
http://cvs.horde.org/diff.php/kronolith/lib/Driver.php?rt=horde&r1=1.116.2.91&r2=1.116.2.92&ty=u

Changes have been made in Git for this ticket:

Support snoozing alarms with Sundbird/Lightning (Request #7470).

http://git.horde.org/horde-git/-/commit/e127c4547813d8d82fdd3a22b943be34f249d28b

Changes have been made in Git for this ticket:

[jan] Support snoozing alarms with Sundbird/Lightning (Request #7470).

  5 files changed, 73 insertions(+), 15 deletions(-)
http://git.horde.org/horde-git/-/commit/7968ea021de356d10580c02ff3be54038c98b17e

The correct solution is outlined in this ticket. Instead of adding a 
new field to the event, the Horde_Alarm backend needs to be updated 
with the snooze information.

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.

My feedback still holds: it has to be cleaned up according to my 
earlier comments, to be accepted upstream.

Anyone use this patch? Seems work for alarm but delete description :-(
Any feedback?

iCalendar patch for Horde 3.3.5 doesn't works.

I make a patch for 3.3.5

It works for me.



Driver[2].patch works correctly

It seems to be fix

I can't apply the iCalendar patch 
/home/httpd/html/horde/lib/Horde/iCalendar.php

Is it included in new kronolith version?

Any update here?

Yes.
Any progress on that?

If tested for this problem with two clients we are using (Funambol 
Outlook 6.x/7.x and Thunderbird/Sunbird Plugin version 0.9).

- Thunderbird (iCal) uses X-MOZ-LASTACK: to signal reset/snooze of 
alarm as addressed in the already commited CVS changes

- Outlook set AALARM to empty to signal snooze as it uses vCalendar 
1.0. This would be addressed in #6658 for SyncML as far as i can see 
so the alarm should get cleared in Kronolith?



Kronolith furthermore ignores VALARM (as defined in iCal Standard) 
when importing. This was addressed in Bug #6665 then transferred to 
#7470 and now the relevant parts of the patch removed for the CVS 
changes??

Sadly enough Kronolith exports iCal with VALARM but at import the 
Alarm is lost.

I will try to modify the rest of the patch to get it clean & acceptable.



Andreas

That should work as long as the client supports *any* way of sending 
snooze information in iCalendar. When sending data from the server to 
the client we could simply use all proprietary methods to provide that 
information that we know and support. If the client doesn't support 
snooze at all, it's useless anyway.

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??

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.
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.
Yes, but that has nothing to do with this request anyway.

20090121 \

- after applying these patches, it works - partly. (using horde v3.3.2 
and kronolith v2.3 - sunbird & lightning v0.9)

- tryied to edit REMINDER(alarm) in existing event, saved and it was 
remembered. fine

- !!! have tryied to snooze (e.g. 5min) it after the event showed up 
first time, but after snoozing never showed up again.



p.s.

- when patching the Driver.php in /kronolith/lib was "squeaking" this:

{

Reversed (or previously applied) patch detected!  Assume -R? [n]

Apply anyway? [n] y

}

- creating the file 'Driver.php.rej' after, which is 4002 bits long, 
containing this:

{

***************

*** 739,744 ****

                   $vAlarm = &Horde_iCalendar::newComponent('valarm', $vEvent);

                   $vAlarm->setAttribute('ACTION', 'DISPLAY');

                   $vAlarm->setAttribute('TRIGGER;VALUE=DURATION', 
'-PT' . $this->alarm . 'M');

                   $vEvent->addComponent($vAlarm);

               }

           }

--- 739,760 ----

                   $vAlarm = &Horde_iCalendar::newComponent('valarm', $vEvent);

                   $vAlarm->setAttribute('ACTION', 'DISPLAY');

                   $vAlarm->setAttribute('TRIGGER;VALUE=DURATION', 
'-PT' . $this->alarm . 'M');

+

+                                                               // 
Send Sunbird/Lightning X-MOZ-LASTACK if the alarm has been dismissed

+                                                               // 
Send X-MOZ-SNOOZE-TIME if it's been snoozed

+                                                               
require_once 'Horde/Alarm.php';

+                                             $currentAlarm = 
Horde_Alarm::factory();

+                                                               
if($currentAlarm->exists($this->_uid, $this->creatorID)) {

+                                                                       
  if($currentAlarm->isSnoozed($this->_uid, $this->creatorID)) {

+                                                                       
          $vEvent->setAttribute('X-MOZ-LASTACK', $modified);

+                                                                       
          $alarmHash = $currentAlarm->get($this->_uid, 
$this->creatorID);

+                                                                       
          if(isset($alarmHash->snooze)) {

+                                                                       
                  $vEvent->setAttribute('X-MOZ-SNOOZE-TIME', 
$alarmHash['snooze']->timestamp());

+                                                                       
          }

+                                                                       }

+                                                               } else {

+                                                                       
          $vEvent->setAttribute('X-MOZ-LASTACK', $modified);

+                                                               }

                   $vEvent->addComponent($vAlarm);

               }

           }

***************

*** 896,902 ****

           } else {

               $duration = $vEvent->getAttribute('DURATION');

               if (!is_array($duration) && !is_a($duration, 'PEAR_Error')) {

-                 $this->end = new 
Horde_Date($this->start->timestamp() + $duration);

               } else {

                   // End date equal to start date as per RFC 2445.

                   $this->end = Util::cloneObject($this->start);

--- 912,918 ----

           } else {

               $duration = $vEvent->getAttribute('DURATION');

               if (!is_array($duration) && !is_a($duration, 'PEAR_Error')) {

+                $this->end = new Horde_Date($this->start->timestamp() 
+ $duration);

               } else {

                   // End date equal to start date as per RFC 2445.

                   $this->end = Util::cloneObject($this->start);

***************

*** 916,922 ****

               $this->alarm = intval(($this->start->timestamp() - 
$alarm) / 60);

           }



-         // @TODO: vCalendar 2.0 alarms



           // Attendance.

           // Importing attendance may result in confusion: editing an imported

--- 932,964 ----

               $this->alarm = intval(($this->start->timestamp() - 
$alarm) / 60);

           }



+                               // Dismissed or Snoozed

+                               // Sunbird/Lightning sends an 
X-MOZ-LASTACK if an alarm is snoozed or dismissed

+                               // It sends an additional 
X-MOZ-SNOOZE-TIME if snoozed with a date stamp

+                               // containing the time the alarm should refire

+                               $dismissed = 
$vEvent->getAttribute('X-MOZ-LASTACK');

+                               $snoozed = 
$vEvent->getAttribute('X-MOZ-SNOOZE-TIME');

+                               if(!is_a($dismissed, 'PEAR_ERROR')) {

+                                       require_once 'Horde/Alarm.php';

+           $currentAlarm = Horde_Alarm::factory();

+                                       if(!is_a($snoozed, 'PEAR_ERROR')) {

+                                         $snoozeTime = new 
Horde_Date(strtotime($snoozed));

+                                               $snoozeLength = 
intval(($snoozeTime->timestamp() - time()) / 60);

+                                               
$currentAlarm->snooze($this->getUID(), $this->getCreatorId(), 
$snoozeLength);

+                                       } else {

+                                               
$currentAlarm->snooze($this->getUID(), $this->getCreatorId(), -1);

+                                       }

+                               }

+

+                               $components = $vEvent->getComponents();

+                               foreach($components as $c) {

+                                       if($c->getType() == 'vAlarm') {

+                                               $myalarm = 
$c->getAttribute('TRIGGER;VALUE=DURATION');

+                                               $this->alarm = 
intval(Horde_iCalendar::_parseDuration($myalarm) / -60);

+                                               $this->save();

+                                               break;

+                                       }

+                               }



           // Attendance.

           // Importing attendance may result in confusion: editing an imported

}



Daniel

If i set alarm event in lightning when syncronize the event in horde, 
the alarm disappear. I i set alarm in horde and syncronize, the alarm 
compare in lightning too.

Jan,

can you clarify the situation where the Driver patch breaks?



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.



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.

I only committed what has been linked in the ticket comments. The 
Kronolith patch has to be redone.

Does this mean it's still not working in the part you just implemented 
in cvs, and I should try to work on it further, or does it appear to 
be functional now?

I dropped most of your iCalendar changes because all that was really 
necessary was to handle the X-MOZ fields as datetime fields.

The problem with your Kronolith patch is, that it breaks BC the way it 
is implemented. Horde_Alarm has been added at a later point, so you 
have to at least check if it exists. Also please try to stick to Horde 
coding standards as close as possible, as this makes it easier to 
integrate patches.

For those following this ticket, I've used the patch successfully 
against Horde Webmail 1.2.1 as well.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/iCalendar/iCalendar.php?rt=horde&r1=1.156&r2=1.157&ty=u

We've been using the patch without issue since I posted it (almost a 
month now.)

You should be able to patch your files by putting the patch files in 
the same directory as the files they patch (horde/lib/Horde/ and 
kronolith/lib) and then navigating to the appropriate directory on the 
command line and issuing:

patch -p0 < iCalendar.patch

or

patch -p0 < Driver.patch



Make sure you backup your iCalendar.php and Driver.php files first so 
you can restore them if necessary.

If you're uncomfortable or just want to test the process you could 
copy the two original files to your personal computer and patch them 
there and then put them back, or you could manually patch them.  You 
can do that by looking in the patch for lines that start with a - and 
removing those from your file and adding the lines that start with a +.

Good luck!

Hey, I'm just wondering the state of this bug.  I have 84 reminders I 
can't dismiss now.  If there's a way for a mere plebeian to apply this 
patch.

New Driver.php patch included.  Jan, as far as I can tell you still 
need the strtotime() though there was an extra line left over from 
testing.  When I run it without that conversion first the timestamp 
comes out off by the difference in GMT to my timezone.



It looks like I might have patched driver against a non-standard file 
as well, that has been rectified.

new iCalendar patch attached.  Based on the Horde Framework 3.3 
download from the main site.

At least the iCalendar.php patch is not against the official version, 
but probably against some earlier patch local modification. Can you 
please upload a fixed patch?

And since you parse the datetime field in iCalendar.php, is the 
strtotime() call in Driver.php still necessary?

Driver patch

After investigating a little bit further I re-wrote this to use 
_exportDateTime which I think will help in solving the daylight 
savings time bug eventually and is more appropriate.  Also condensed 
some of the export code since we were just setting attributes on both.



See the next post for the second patch.

I should note this patch includes the patch from here:

http://bugs.horde.org/ticket/6665

as that wasn't incorporated in 2.3.  This is simply a more complete 
implementation.

Second patch attached here

Subscribing to an ics file via the rpc.php file and kronolith stores 
and returns alarms but not dismissals or snoozes.  This causes alarms 
to fire every time the remote calendar is refreshed and can lead to 
mental instability.



It appears that there is no specification for sending alarm dismissals 
or snoozes to and from a server which would lead one to believe that 
they should be stored on the client.  Sadly Sunbird and Lightning send 
these items with their own tags in the ics file and expect to get them 
back when they refresh their calendars.



It appears that groupware implementations are starting to implement 
some version of this unofficial system to stop their users from going 
insane clicking dismiss every five or ten minutes.  Bedework has 
implemented dismissals by storing the X-MOZ-LASTACK as sent by Sunbird 
and then returning the value when the calendar is next requested.



I thought it would be slightly nicer if the data was stored in the 
appropriate locations within horde and kronolith so that the same 
alarms do not fire in kronolith after they have been dismissed by 
Sunbird and vice versa.



Attached is my proposed fix.  It may not be the most efficient way of 
solving the problem, but it seems to work in our minimal testing.

Here's how it attempts to work:



1. Sunbird requests an ics file

2. Horde checks to see if the alarms have been dismissed or snoozed 
and returns an X-MOZ-LASTACK if dismissed and an additional 
X-MOZ-SNOOZE-TIME if snoozed based on horde_alarms

3. Sunbird dismisses or snoozes an event

4. Horde updates the alarm_snooze and alarm_dismissed columns in 
horde_alarms accordingly



The attached patches are for lib/Horde/iCalendar.php and 
kronolith/lib/Driver.php and are based off of the kronolith 2.3 
release (Webmail 1.2)