I can confirm the bug under Icedove 17.0.10 + Lightning 1.9.1 under RHEL 6.4 + EPEL, working against Zimbra 8.0.6_GA_5922 (build 20131203103753).
Not sure if you consider this a reliable calendaring server, but it has nothing to do with Google :-P
The issue appears only with recurring events I create myself. I guess (!) that it might be series where I have modified one individual appointment. My workaround is to remove the alarm from the specific appointment causing the trouble, then the reminder disappears. Some people seem to say that alarms coming after the "sticky reminder" would also stick; I can NOT confirm this observation.
If I set the debug options as suggested, and dismiss the sticky reminder, I get 3 events in the console:
I can confirm the bug under Icedove 17.0.10 + Lightning 1.9.1 under RHEL 6.4 + EPEL, working against Zimbra 8.0.6_GA_5922 (build 20131203103753).
Not sure if you consider this a reliable calendaring server, but it has nothing to do with Google :-P
The issue appears only with recurring events I create myself. I guess (!) that it might be series where I have modified one individual appointment. My workaround is to remove the alarm from the specific appointment causing the trouble, then the reminder disappears. Some people seem to say that alarms coming after the "sticky reminder" would also stick; I can NOT confirm this observation.
If I set the debug options as suggested, and dismiss the sticky reminder, I get 3 events in the console:
CalDAV: Item modified successfully on Zimbra Calendar ner=undefined /mail.corp. redhat. com/dav/ elavarde% 40redhat. com/Calendar/ ries.length= 0 rties] Applying filter:
--
aChangeLogListe
calendarURI=https:/
iscached=true
this.mQueuedQue
--
[calFilterPrope
start: 4
end: P7D
status: null
due: null
category: null
--
and the event doesn't disappear.
Hope this helps fix the issue...