Closed
Bug 435898
Opened 16 years ago
Closed 15 years ago
confirming already confirmed alarm sets online calender to read-only
Categories
(Calendar :: Alarms, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 327933
People
(Reporter: languitar, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.14) Gecko/20080420 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.8.1.13pre) Gecko/20080524 Sunbird/0.8
I'm using Sunbird most of the time on two computers in parallel. Both use the same ics-calendars via webdav. If an alarm pops up and I confirm it on one computer, the second Sunbird doesn't recognize this and confirming that alarm there again, results in an error. Afterwards the calendar is set to read-only mode. This is especially annoying as there is no real cancel-button. There's only the tiny X of the window manager.
Reproducible: Always
Steps to Reproduce:
1. start Sunbird on two computers, both using the same ics online calendars (webdav)
2. wait for an alarm that pops up on both computers
3. confirm it on one computer
4. confirm it on the second
Actual Results:
The second Sunbird instance detects an error in writing the calendar file and sets it to read-only.
Expected Results:
The second instance notices that the alarm was confirmed before and simply does nothing. Maybe one could show a warning but that would be another needless click for my purpose. At least it should be possible for Sunbird to assume that one confirmation of the alarm is enough and the second is only because that instance of Sunbird didn't reload the calendar fast enough.
Maybe it would be desirable, too, that Sunbird automatically removes the alarm if it detects a confirmation in the online calendar. This is especially useful because I use hibernation on my laptop so that Sunbird doesn't restart completely on wakeup. As a consequence calendars aren't reloaded and all alarms within the time since hibernation pop up at once, even though they were all confirmed on another computer.
I understand that this is a topic that mainly depends on the usage of the online calendar. If it is used by multiple persons, such an automatic behaviour would be useless. I think a personal configuration can solve this. At least the switching to read-only should be removed.
Comment 1•16 years ago
|
||
You can avoid this by reloading the calendar first. Or set it to automatically reload every X minutes via preference dialog.
This is most probably a duplicate of one of the always-reload-before-write or precondition-failed bugs. Please check Tools -> Error Console and copy+paste the error messages you see.
Reporter | ||
Comment 2•16 years ago
|
||
Well, how should I reload it, if it pops up with the notification directly after wakeup from hibernation? Nevertheless that not really a thing I want to do manually.
Here the debug information:
The error dialogue says:
Error number: 0x0
Description: Publishing the calendar file failed
Status code: 412: Precondition Failed
Error console doesn't show anything.
Comment 3•16 years ago
|
||
I don't understand your last scenario, your computer tries to write a modified event the moment it wakes up from hibernation? This doesn't seem like bug 327933 but the error you report does.
Reporter | ||
Comment 4•16 years ago
|
||
No, the moment it wakes up it shows all alarms that were in the time since hibernation. It doesn't reload the calendar before, so this can be a bunch of alarms that cannot be confirmed because I have confirmed them before on another computer.
Updated•15 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•