Tickets :: Comment on [#12286] Problem dismissing Horde events with Lightning

* Your Email Address
* Spam protection	Enter the letters below: .__ .___..___ __ ._. \| \ \| [__ / ` \| \|__/ \| [___\__._\|_
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. > > >
Attachment
Watch this ticket

Saved Queries