[Tickets #12286] Problem dismissing Horde events with Lightning
noreply at bugs.horde.org
noreply at bugs.horde.org
Fri May 31 10:44:27 UTC 2013
BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE
E-MAIL-ADRESSE WERDEN NICHT GELESEN.
Ticket-URL: http://bugs.horde.org/ticket/12286
------------------------------------------------------------------------------
Ticket | 12286
Erstellt Von | schell at iup.physik.uni-bremen.de
Zusammenfassung | Problem dismissing Horde events with Lightning
Warteschlange | Kronolith
Version | 4.0.4
Typ | Bug
Status | Unconfirmed
Priorität | 1. Low
Milestone |
Patch |
Zuständige |
------------------------------------------------------------------------------
schell at iup.physik.uni-bremen.de (2013-05-31 10:44) hat geschrieben:
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.
More information about the bugs
mailing list