6.0.0-beta1
7/17/25

[#12286] Problem dismissing Horde events with Lightning
Summary Problem dismissing Horde events with Lightning
Queue Kronolith
Queue Version 4.0.4
Type Bug
State No Feedback
Priority 1. Low
Owners
Requester schell (at) iup (dot) physik (dot) uni-bremen (dot) de
Created 05/31/2013 (4430 days ago)
Due
Updated 08/27/2013 (4342 days ago)
Assigned 07/02/2013 (4398 days ago)
Resolved 08/27/2013 (4342 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
08/27/2013 10:35:45 AM Jan Schneider State ⇒ No Feedback
 
07/02/2013 10:56:44 PM Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Please try Kronolith 4.1.
05/31/2013 10:44:26 AM schell (at) iup (dot) physik (dot) uni-bremen (dot) de Comment #1
Priority ⇒ 1. Low
Patch ⇒ No
Milestone ⇒
Queue ⇒ Kronolith
Summary ⇒ Problem dismissing Horde events with Lightning
Type ⇒ Bug
State ⇒ Unconfirmed
Reply to this comment
Following all informations also posted in mailinglist

------------------------------------

short time ago we upgraded our Horde from 3.3.9 to 5.0.4.
New server, new installation, migrated old DB.

So far everything worked fine but we face one problem.

The Horde-Calendar is embedded in Thunderbird/Lightning as remote 
calendar via https://servername/rpc.php/kronolith/user/user.ics

If we now have an event with alarm and the reminder in Lightning comes 
up and is dismissed, after some time the reminder comes up again and 
again. It harasses until you e.g. edit the event and disable the alarm.

Yes... The remote calendar is writable.

If we observe the horde-db we can see the new event with alarm in 
table horde_alarms with field alarm_dismissed set to 0.
After the event came up in Lightning and got dismissed alarm_dismissed 
changes to 1 and the entry in horde_alarms disappears anytime later.
And event_alarm_methods in kronolith_events changes to N; (is N; correct?)

But unfortunately sometimes later the alarm comes up in lightning 
again and the entry in horde_alarm appears again. But this time 
instantly with alarm_dismissed set to 1.

With version 3.3.x we didn't see this issue.
We also compared two entries with alarm in kronolith_events written 
with old horde and new horde and have seen that the field alarm_method 
from dismissed events of old horde is set to NULL and new horde set it 
to N;

Comparison of two events in the ics-backup in thunderbird folder 
brought no news both entries have the same syntax.

I'm not quite sure if it's a problem with Lightning ?
Some forum-entries found concerning Lightning dismissal mostly deal 
with different issues or show workarounds to get rid of the harassing 
reminders but no real solution.

Or is it a problem with horde maybe caused by the schema update during 
upgrade ? (we also ran convert-to-utc)

-------------------------------------------------
How does the exported (from Horde to iCalendar) event look like?
Here the extract from local ics-Backup in 
.thunderbird/..../calendar-data/backup/cal_xxxx.ics

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20130530T124500Z
DTEND;TZID=Europe/Berlin:20130530T130000Z
DTSTAMP:20130530T124225Z
UID:1a25949b-bc4d-4d06-ba85-dda485b2d3e9
CREATED:20130530T123637Z
LAST-MODIFIED:20130530T123637Z
SUMMARY:alarmtestevent
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:alarmtestevent
TRIGGER;VALUE=DURATION:-PT5M
END:VALARM
END:VEVENT


extract from ics-file exported from Horde webfrontend before dismiss

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20130530T124500Z
DTEND;TZID=Europe/Berlin:20130530T130000Z
DTSTAMP:20130530T124133Z
UID:1a25949b-bc4d-4d06-ba85-dda485b2d3e9
CREATED:20130530T123637Z
LAST-MODIFIED:20130530T123637Z
SUMMARY:alarmtestevent
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:alarmtestevent
TRIGGER;VALUE=DURATION:-PT5M
END:VALARM
END:VEVENT


extract from ics-file exported from Horde webfrontend after dismiss

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20130530T124500Z
DTEND;TZID=Europe/Berlin:20130530T130000Z
DTSTAMP:20130530T124522Z
UID:1a25949b-bc4d-4d06-ba85-dda485b2d3e9
CREATED:20130530T123637Z
LAST-MODIFIED:20130530T124230Z
SUMMARY:alarmtestevent
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
X-MOZ-LASTACK:20130530T124522Z
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:alarmtestevent
TRIGGER;VALUE=DURATION:-PT5M
END:VALARM
END:VEVENT



Maybe this helps / maybe it has to be:

Around 15 minutes after I dismissed the event I again exported the ics 
from webfrontend to check if it maybe changes and it did.
I have seen that for the event the X-MOZ-LASTACK tag disappeared.

Just two minutes ago the reminder came up again in lightning and after 
dismissing once more the X-MOZ-LASTACK entry appeared again in ics 
file at server.


--------------------------------------------------------------
This means that Kronolith no longer considers the event alarm as 
dismissed. You should also get an alarm notification in the 
interface then though.
No. I only get the first event notification.

By default my Kronolith is setup (and so it was in 3.3.x) to send me a 
mail X minutes (depending on event)  before.  And it also only sends 
it once.  Even if the event comes up again in Lightning and 
horde_alarms I don't get further mails.

As I thought maybe the alarm settings in interface and in Lightning 
tread each other on the toes I completely switched off the 
notifications sent from Kronolith but it didn't effect the behavior of 
Lightning so I switched it on again.

As I don't use the interface that much and mostly rely on Lightning I 
don't use notifications in browser etc.
But I'll change the notification settings in interface tomorrow 
morning to "desktop" or "in text" and see what happens together with 
the dismissals of my Lightning at work.


-----------------------------------------------------

As mentioned before I did some tests with in-text notifications in 
webinterface together with Lightning to check this behavior.

The in-text notification comes up only once. Without reference if I 
dismiss the event in interface or click it away and dismiss in 
Lightning.


During my tests I've observed the following things that may help you 
analyze the issue.

* I created the event in interface and as the notification came up I
   dismissed in interface. Then waited until the alarm disappeared in
   horde_alarms and startet Thunderbird/Lightning.
   The reminder came up immediately. So it seems Lightning didn't get to
   know that this event was already dismissed by another client (be that
   the browser or Lightning). Or as collegues do, to use Lightning at
   work and at home.

* As I dismissed the event in interface the entry of
   event_alarm_methods in kronolith_events didn't change.
   As I dismissed it in Lightning event_alarm_methods changed to N;

* As I once clicked away the reminder popup in Lightning without
   dismissing, Lightning wrote a new entry to horde_alarms setting a
   snooze of 5 minutes and set dissmissed to 0

* By accident I had both the Browser and Lightning opened the same time
   and deleted two events in interface. Minutes later they materialised
   again in interface. By this I realized that I forgot to close
   Lightning and it seemed to have synced that time.

   Okay that's not the correct way to use it (having two clients the
   same time) and who shall decide which is the correct information.
   But it seems Lightning during sync takes itself more important than
   the server and uploads it's informations.



Saved Queries