6.0.0-git
2019-07-17

[#7470] Sunbird/Lightning alarm dismissal and snooze incompletely implemented
Summary Sunbird/Lightning alarm dismissal and snooze incompletely implemented
Queue Kronolith
Queue Version Git master
Type Enhancement
State Resolved
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester elliot (at) marlboro (dot) edu
Created 2008-10-10 (3932 days ago)
Due
Updated 2014-05-27 (1877 days ago)
Assigned 2011-08-10 (2898 days ago)
Resolved 2011-08-12 (2896 days ago)
Milestone
Patch No

History
2014-05-27 14:44:37 Jan Schneider Comment #38 Reply to this comment
2013-10-14 10:06:49 carlosamarantino (at) gmail (dot) com Comment #37 Reply to this comment
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?
Same problem here. Kronolith v4.1.2, Thunderbird v24.0, Lightning v2.6
(Ubuntu, Linux)
2012-04-25 08:04:10 pla (at) etla (dot) fi Comment #36 Reply to this comment
Same problem here. Kronolith 3.0.16, Thunderbird 11.0.1, Lightning 1.3 
(Ubuntu, Linux)
2012-04-25 07:13:44 michael (dot) groene (at) zel (dot) uni-hannover (dot) de Comment #35 Reply to this comment
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?
2011-08-12 12:23:47 Jan Schneider State ⇒ Resolved
 
2011-08-12 12:23:36 Git Commit Comment #33 Reply to this comment
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
2011-08-12 12:23:31 Git Commit Comment #32 Reply to this comment
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
2011-08-10 14:04:54 Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
 
2011-06-30 16:13:37 Jan Schneider Comment #31
Taken from Horde DevelopersHorde Developers
State ⇒ Feedback
Version ⇒ Git master
Reply to this comment
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).
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.
2011-04-29 20:46:01 spamstop1 (at) terriertech (dot) com Comment #30
New Attachment: Snooze.patch Download
Reply to this comment
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.
2009-12-02 09:38:14 Jan Schneider Comment #29 Reply to this comment
My feedback still holds: it has to be cleaned up according to my 
earlier comments, to be accepted upstream.
2009-12-02 08:10:32 alessio (dot) fattorini (at) nethesis (dot) it Comment #28 Reply to this comment
Anyone use this patch? Seems work for alarm but delete description :-(
Any feedback?

2009-12-01 22:49:41 Jan Schneider Deleted Original Message
 
2009-12-01 22:49:16 Jan Schneider Deleted Original Message
 
2009-10-29 09:59:34 alessio (dot) fattorini (at) nethesis (dot) it Comment #27
New Attachment: iCalendar_335.php Download
Reply to this comment
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
2009-09-28 14:24:42 alessio (dot) fattorini (at) nethesis (dot) it Comment #26
New Attachment: iCalendar.php.rej
Reply to this comment
I can't apply the iCalendar patch 
/home/httpd/html/horde/lib/Horde/iCalendar.php
2009-09-28 13:16:57 alessio (dot) fattorini (at) nethesis (dot) it Comment #25 Reply to this comment
Is it included in new kronolith version?
2009-06-28 16:26:19 Chuck Hagenbuch State ⇒ No Feedback
 
2009-06-01 19:59:55 Chuck Hagenbuch Comment #24 Reply to this comment
Any update here?
2009-04-29 16:11:39 Jan Schneider Comment #23 Reply to this comment
- 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?
Yes.
I will try to modify the rest of the patch to get it clean & acceptable.
Any progress on that?
2009-03-27 10:25:30 lst_hoe02 (at) kwsoft (dot) de Comment #22 Reply to this comment
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


2009-03-25 16:45:19 Jan Schneider Comment #21
State ⇒ Feedback
Reply to this comment
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.
2009-03-25 12:53:47 lst_hoe02 (at) kwsoft (dot) de Comment #20 Reply to this 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??
2009-03-09 00:43:28 Chuck Hagenbuch State ⇒ No Feedback
Patch ⇒ No
 
2009-01-29 11:31:22 Jan Schneider Comment #19 Reply to this comment
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.
2009-01-21 14:47:59 b5b5b5b5 (at) centrum (dot) sk Comment #18 Reply to this comment
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
2009-01-20 14:33:59 alessio (dot) fattorini (at) nethesis (dot) it Comment #17 Reply to this comment
Jan,
can you clarify the situation where the Driver patch breaks?
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.


2009-01-12 18:35:52 elliot (at) marlboro (dot) edu Comment #16 Reply to this comment
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.
2009-01-07 13:58:42 Jan Schneider Comment #15 Reply to this comment
I only committed what has been linked in the ticket comments. The 
Kronolith patch has to be redone.
2009-01-07 13:52:42 elliot (at) marlboro (dot) edu Comment #14 Reply to this comment
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?
2009-01-07 13:49:32 Jan Schneider Comment #13
State ⇒ Feedback
Reply to this comment
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.
2009-01-07 13:44:20 elliot (at) marlboro (dot) edu Comment #12 Reply to this comment
For those following this ticket, I've used the patch successfully 
against Horde Webmail 1.2.1 as well.
2008-11-12 12:12:11 elliot (at) marlboro (dot) edu Comment #10 Reply to this comment
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!
2008-11-12 06:10:11 horde (at) chaosmt (dot) net Comment #9 Reply to this comment
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.
2008-10-19 16:54:10 Jan Schneider Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Patch ⇒ Yes
 
2008-10-19 16:53:54 Jan Schneider Deleted Original Message
 
2008-10-19 16:53:47 Jan Schneider Deleted Original Message
 
2008-10-14 22:01:40 elliot (at) marlboro (dot) edu Comment #8
New Attachment: Driver[2].patch Download
Reply to this comment
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.
2008-10-14 21:53:57 elliot (at) marlboro (dot) edu Comment #7
New Attachment: iCalendar[2].patch
Reply to this comment
new iCalendar patch attached.  Based on the Horde Framework 3.3 
download from the main site.
2008-10-14 17:35:05 Jan Schneider Comment #6
State ⇒ Feedback
Reply to this comment
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?
2008-10-14 17:20:43 Jan Schneider Deleted Original Message
 
2008-10-14 17:20:37 Jan Schneider Deleted Original Message
 
2008-10-14 17:19:59 Jan Schneider Type ⇒ Enhancement
State ⇒ Accepted
Priority ⇒ 2. Medium
 
2008-10-13 01:17:05 elliot (at) marlboro (dot) edu Comment #5
New Attachment: Driver[1].patch
Reply to this comment
Driver patch
2008-10-13 01:14:42 elliot (at) marlboro (dot) edu Comment #4
New Attachment: iCalendar[1].patch
Reply to this comment
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.
2008-10-10 20:25:59 elliot (at) marlboro (dot) edu Comment #3 Reply to this comment
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.
2008-10-10 17:33:38 elliot (at) marlboro (dot) edu Comment #2
New Attachment: Driver.patch
Reply to this comment
Second patch attached here
2008-10-10 17:32:23 elliot (at) marlboro (dot) edu Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Sunbird/Lightning alarm dismissal and snooze incompletely implemented
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ Yes
New Attachment: iCalendar.patch
Reply to this comment
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)


Saved Queries