New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Popup alarms/reminders don't work with WCAP server (Bugzilla Bug 380423) #2
Comments
Comment 3183118Date: 2007-05-11 19:56:34 +0200 Set a WCAP network calendar and set an event with alarm. Alarm never goes off. The remote WCAP server is out of my control and is in beta and having connection issues, but even if remote server is disconnected local calendar knows about event and shows it, so shouldn't alarm be going off? |
Comment 3183215Date: 2007-05-11 21:44:17 +0200 Hi, do you mixed up some things? Are you using a locale calendar or are you using a remote calendar on a Sun Java System Calendar Server? In the latter case you always need a connection to the server to view/edit/create events. |
Comment 3183229Date: 2007-05-11 22:03:23 +0200 Using a remote calendar on a Sun Java System Calendar Server. Yea I am connected to the server when I create the event, I can confirm that the event is viewable on my local computer and the remote webpage on the server. The alarm inside thunderbird never fires. I don't know if it has to do with the connection issue (it times out frequently) or what, but seems to me it holds a local cache and should fire from that independent of connection.?? |
Comment 3183714Date: 2007-05-12 15:44:57 +0200 This feature is currently not implementable, because X-props can't be saved (more specifically replaced) reliably. Right now, if you specify an alarm (and you have defined an email address in your calendar settings), an email notification alarm is set on the server using the respective time offset. I change this bug to RFE, still on my list, of course. |
Comment 3356950Date: 2007-10-31 13:52:56 +0100 We might head towards a solution for WCAP popup alarms when we have offline support: We could keep the full calendar data (including alarm definitions/dismiss stamps) locally, while we omit those data (e.g. X-prop dismiss stamps) when writing to the server. |
Comment 3502100Date: 2008-02-27 19:49:38 +0100 *** Bug #419871 has been marked as a duplicate of this bug. *** |
Comment 3662296Date: 2008-06-15 18:32:41 +0200 *** Bug #439329 has been marked as a duplicate of this bug. *** |
Comment 3688307Date: 2008-07-02 06:12:27 +0200 Is this going to be fixed when the offline support is available with M9 build? The approach suggested by Daniel on 1007-05-12 is the approach Outlook Connector uses for popup alarms too. |
Comment 3689119Date: 2008-07-02 20:25:37 +0200 Any solution that allows me to configure the alarm behavior in the server so |
Comment 3694131Date: 2008-07-07 18:52:13 +0200 (In reply to comment #7)
|
Comment 3728230Date: 2008-08-05 06:42:47 +0200 *** Bug #449166 has been marked as a duplicate of this bug. *** |
Comment 3997117Date: 2009-03-02 21:02:54 +0100 Following changes will make alarm reminders work with Sun System Calendar Server (WCAP): Instead of using the X-props you should use the alarmOffset parameter of the calendar event item. If an alarm is fired and the user selects: b) snooze alarm |
Comment 3997126Date: 2009-03-02 21:06:58 +0100 Created attachment 364975
|
Comment 3997255Date: 2009-03-02 22:19:37 +0100 So to make them "work", you remove the actual offset? Also, please note that the alarm service will change quite a bit in 1.0pre. |
Comment 3997349Date: 2009-03-02 23:12:31 +0100 Yes, i replace the actual offset with the user selection (dismiss,snooze). I think that the replacement of the offset is better than not having a alarm reminder ;-) By the way:
|
Comment 3997425Date: 2009-03-02 23:52:59 +0100 Comment on attachment 364975
|
Comment 3997440Date: 2009-03-02 23:59:22 +0100 Created attachment 365040 Comment #15 should be remove...sorry... Changed the snoozeAlarm behaviour. My changes now only affect WCAP calendar.
|
Comment 3998102Date: 2009-03-03 09:04:20 +0100 Please only post patches instead of whole files, its really hard to understand this way. Also, make sure you are using the latest version of the file. See https://developer.mozilla.org/En/Creating_a_patch and https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_diff_and_patch_files.3F |
Comment 3998112Date: 2009-03-03 09:15:51 +0100 Sorry! I only modified the "snoozeAlarm" and "dismissAlarm" methods. |
Comment 4000330Date: 2009-03-04 18:20:29 +0100 (In reply to comment #14)
|
Comment 4010468Date: 2009-03-11 10:03:13 +0100 *** Bug #482544 has been marked as a duplicate of this bug. *** |
Comment 4017878Date: 2009-03-16 11:43:14 +0100 I think maybe this bug is in relation with this other Bug #474426, am I right? |
Comment 4119826Date: 2009-05-28 21:49:41 +0200 Adding relnote keyword unless we gonna fix this for 1.0... |
Comment 4633754Date: 2010-04-12 15:15:50 +0200 *** Bug #558755 has been marked as a duplicate of this bug. *** |
Comment 4633758Date: 2010-04-12 15:17:43 +0200 I've downloaded the calAlarmService.js file (which was attached to that bug) and replaced all this files in my system, but it doesn't resolve this issue. Maybe i did it wrong (means I should apply fixed calAlarmService.js in the different way – not simply replace the files?) |
Comment 7329244Date: 2013-04-18 11:07:10 +0200 This bug is still present with Google Calendar notifications, they don't pop-up. Using the Lightning plugin on Ubuntu 12.04. |
Comment 7478615Date: 2013-05-30 12:38:21 +0200 It would also be a big step forward if you could just provide an option to display a popup at the email alarm time, as a workaround. Thus, it'd be usable for now even if I get the additional email notification from the server which I can easily filter to /dev/null. For me, without popup reminders the WCAP functionality is quite useless - I reliably notice the email quite a long time after the meeting has startet. 8-} |
Bugzilla Bug 380423
Date: 2007-05-11T19:56:34+02:00
From: jlarsen@fsu.edu
Assigned To: nobody
Last updated: 2013-05-30T12:38:21+02:00
The text was updated successfully, but these errors were encountered: