Closed Bug 356002 Opened 19 years ago Closed 7 years ago

Cannot dismiss/snooze alarms from read-only calendar

Categories

(Calendar :: Alarms, defect)

Product:
Calendar
Component:
Alarms
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nemecek, Assigned: MakeMyDay)

References

(Depends on 1 open bug)

Details

(Whiteboard: [has l10n impact])

Attachments

(1 file, 6 obsolete files)

AllowDismissingAlarmsForReadonlyCalendars-V3.diff
21.65 KB, patch
MakeMyDay
: review+
Details | Diff | Splinter Review
User-Agent: Opera/9.02 (Windows NT 5.1; U; en) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3 When a calendar is opened in read-only mode you cannot dismiss/snooze the alarm for an event/task. Reproducible: Always Steps to Reproduce: 1. Create an event/task with an alarm 2. Set the calendar in read-only mode 3. Wait for the alarm to be triggered 4. Try to dismiss or snooze the item that triggered the alarm Actual Results: You cannot dismiss or snooze the item that triggered the alarm. Using the "Dismiss all" button works. Of course, the next time the calendar is loaded, the alarm pops up again. Expected Results: Several possibilities a. The alarm should be dismissed, even if the information that it has been dismissed cannot be stored. b. An info message should be displayed (once?), explaining to the user why the alarm could not be dismissed.
similar to bug 354883 which describe this problem for remote calendars
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am experiencing this on Thunderbird 1.5.0.10 with Lightening build 2007040406 - and the alarms appear even when the "Show an alarm box" and "Show missed alarms" options are turned off. I am about to disable the "Refresh calendars every n minutes" option to make these go away, but this reduces the utility of the calendar application somewhat.
(In reply to comment #3) > I am experiencing this on Thunderbird 1.5.0.10 with Lightening build 2007040406 > - and the alarms appear even when the "Show an alarm box" and "Show missed > alarms" options are turned off. I am about to disable the "Refresh calendars > every n minutes" option to make these go away, but this reduces the utility of > the calendar application somewhat. > i'm having the exact same problem! and i have shared *.ics calendars in my list and always see all the alarms eventhough the calendars are read-only. turning off the alarm options in the about:config doesn't have any effect on actually turning off the alarms, they keep popping up. using Thunderbird 2.0.0.0 (X11/20070326)
This problem is still present in the Lightning 0.7rc1 release.
OS: Windows XP → All
Hardware: PC → All
We have a per-calendar setting for alarms now as a workaround. We could set this to WFM. However if laoding a calendar fires an error and switches to read-only, we will still experience this.
We should disable the Snooze and Dismiss buttons, and maybe offer a Close/Cancel button for that use case. Christian, what do you think?
Don't think that's the right way, an alarm-window can have events for multiple calendars, some of which are readonly and some are readwrite. After some thinking I guess just dismissing the alarms (in memory) until the next reload/restart would be one solution. Can we set a temporary "show no alarms" on a calendar like it's being non-persistantly set to be read-only on a faulty calendar? Whenever a calendar fires an error reading or writing it could not only be set to readonly but it could also be set to not show the alarms, thus avoiding having to dismiss.
Just an idea: a button for switching "show alarms" on/off for all calendars at once would be nice.
(In reply to comment #11) > I guess just dismissing the alarms (in memory) until the next > reload/restart would be one solution. +1 for allowing to dismiss/snooze alarms on read-only calendars even though this won't be saved in the calendar. Lightning could also explain this to users and ask if they want to stop showing alarms for this calendar. > Whenever a calendar fires an error reading or writing it could > not only be set to readonly but it could also be set to not show > the alarms, thus avoiding having to dismiss. -1 for this because if there's a network problem and Lightning sets my calendar to readonly, I still want to receive my alarms because they're important! :)
The problem here is that clicking Snooze and Dismiss is considered an "edit" of the event. As I suggested in Bug 405480, it doesn't make any logical sense for these two actions to be considered being edits to the event, you're not actually changing anything about the actual event! I would suggest that for this aspect of the bug, you MUST allow snooze and dismiss, even if the calendar is Read-only, because A- you're not actually changing the event, and B- just because I mark a calendar read-only it's not the same as saying I don't want to see the event, or their notifications. In my eyes, Event Notifications are part of the "Read" aspect. Read-only should ONLY mean that you don't want the details of the calendar in question to be editable, including notifications in that definition makes no sense.
(In reply to comment #14) > The problem here is that clicking Snooze and Dismiss is considered an "edit" of > the event. As I suggested in Bug 405480, it doesn't make any logical sense for > these two actions to be considered being edits to the event, you're not > actually changing anything about the actual event! This is by design in the RFC so you can dismiss alarms on one computer and avoid having alarms on the next computer.
I have the following situation (related to this bug report): - There is a 'master' calendar that is accessible read/write over WebDAV by a few people - There is a 'read-only' calendar that is accessible read-only over WebDAV (system user 'apache' does not have write rights to the file) by all other employees The 'master' calendar is copied over the 'read-only' calendar every few minutes by a cronjob on the WebDAV server. This setup is quite useful and works very well to publish events of general interest to all employees. Now the problem is, even though the 'read-only' calendar is marked read-only in Sunbird on every single user's installation, Sunbird tries to write-access the calendar to write the 'X-MOZ-LASTACK:...' when the user acknowledges an event notification, but doesn't succeed, because the server prevents the write access from happening. This means, every user gets an ugly error message from Sunbird, and, even worse, the notification will pop up again after the automatic refresh from the server (every few minutes). This renders the whole notification thing unusable for our setup. I'd like to have a 'real read-only' option for the calendars, that store the dismiss/snooze info locally, and not on the server.
(In reply to comment #16) > This is by design in the RFC so you can dismiss alarms on one computer and > avoid having alarms on the next computer. So the issue is obviously then that the RFC to which you're referring isn't wide enough in scope to include "read-only" calendars (I don't know I haven't read the RFC). And IF the RFC doesn't encompass the needs of Calendar, then it stands to reason that following the RFC to the letter doesn't make sense. Either that or Calendar's implementation of the RFC isn't correct. And besides, that'd only be a problem for remote calendars. For my single local calendar which isn't going to be on any "next computer", it's a non-issue. Anyway, the solution seems simple. Store the dismiss/snooze status of an event/task locally in a non-readonly database table SEPARATELY from the calendar in question (whether it's a remote or local calendar). If the calendar is remote and never becomes readwrite, at least you won't be annoyed with notifications EVER coming up on the same computer. Then if the calendar in question becomes readwrite, transparently update the dismiss/snooze status on the actual event.. Or have a popup that asks for permission to update the statuses, ie: "The calendar [name], has been detected as being writable. Would you like to update event/task notification status?".. then you could either have "ALL" and "None" buttons or list the individual tasks and events and allow updating each individually.
(In reply to comment #18) > So the issue is obviously then that the RFC to which you're referring isn't > wide enough in scope to include "read-only" calendars (I don't know I haven't > read the RFC). The RFC being referred to is rfc2445 and is about calendar. Alarms and how they should be dismissed might be a shortcoming, there is the rfc2445bis draft, I'm not sure there is much new things regarding alarms. Many applications build on local databases. > Anyway, the solution seems simple. Store the dismiss/snooze status of an > event/task locally in a non-readonly database table SEPARATELY from the > calendar in question (whether it's a remote or local calendar). If the calendar > is remote and never becomes readwrite, at least you won't be annoyed with > notifications EVER coming up on the same computer. We have already been thinking of a local database for snoozing/dismissing alarms on readonly calendars and also including other data. To do this in a conceptually complete way, its not as simple as it may seem. It would probably be best if this database would not only be able to save alarms, but also arbitrary other data (i.e letting you add description to substitute for notes on a work calendar). I was thinking a sort of "ICS overlay", that might not contain valid ICS events, but something similar that holds all data that cannot be saved on the readonly calendar. This could possibly even be saved on a remote webdav store, to be able to sync dismissal of alarms between two computers that both have access to the same readonly calendar. This would be very Mozilla Calendar specific though. Aside from this idea, synchronizing the data back to the remote events is probably also something that will need to happen for read-write offline support since its the same matter: The remote calendar is not accessible, but changes still need to be remembered and replayed when going online/leaving readonly mode.
(In reply to comment #19) > Aside from this idea, synchronizing the data back to the remote events is > probably also something that will need to happen for read-write offline support > since its the same matter: The remote calendar is not accessible, but changes > still need to be remembered and replayed when going online/leaving readonly > mode. Similar to what I think about it. We need merging of concurrent changes (local/remote) either way for full offline support. So w.r.t. the mentioned scenario, the remote calendar will always be merged into the local one (notifying conflicts of course) while local changes won't. This would allow local changes (notes, alarms etc.) while keeping the local copy updated (subscription model). However I am asking myself whether we should disallow major changes to items, e.g. modification of start/end would hardly make any sense IMO.
I might add that the problem of annoying pop ups that won't go away also occurs when using the XML format suggested by Google. Wim ( Yeah - Rookie! )
We are seeing similar issues with CalDAV calendars as well which are read-write.
IMHO there could be even a general option or better per calendar one on dismissing just for myself or for all calendar viewers. Idea being that several employees may just snooze or dismiss an alarm in a different moment or even miss an alarm if somebody else dismisses it. This is a very likely scenario for shared cals. (though subscribing instead of opening may do ..) On this idea, the read only check may just be the option I'm talking about. If read only, I snooze/dismiss just for myself, if can write, dismiss for all. I wonder if it's not more intuitive this way, seeing a read only lock there telling me I only act on my machine, not on original file accessed by others. Anyway, still in 0.9pre 2008081319, any chance for wanted 1.x?
I am using under WinXP Thunderbird Portable (2.x) and Lightning. My remote ICS calendar (read-write) is hosted by Memotoo. Since a few weeks this bug occurs in my calendar.
We're seeing this with read-write as well as read-only calendars coming out of kronolith. It appears that kronolith doesn't currently support the X-MOZ-LASTACK dismissal that Sunbird places in the ics file it sends back. I've yet to find anything in the iCalendar standard that specifies how dismissals should be treated which leads me to believe that perhaps it should be handled on the client side and clients should not (at least for now) expect a server to notify clients of dismissed alarms. I propose (knowing very little about how Sunbird stores remote calendars) that Sunbird maintain some local data associated with each remote calendar, even a simple list of event ids that have been dismissed which it checks before displaying any alarms would probably solve the problem. If the event id is in the list, don't display the alarm. If someone dismisses an alarm, note the event id in that file.
If you are using horde/kronolith there is now a patch available to fix this on calendars you have write access too. http://bugs.horde.org/ticket/7470
The horde issue was a server problem with a read-write calendar, not a lightning problem. It doesn't actually have anything to do with this bug, which is about lightning being unable to snooze/dismiss read-only calendars.
It has to do with lightning in that lightning is expecting the server to send the alarm snooze/dismiss information in the ics file. If the ics file arrives with the X-MOZ-LASTACK and X-MOZ-SNOOZE-TIME appropriately coded the alarm doesn't fire.
But the bug wasn't in lightning, it was in Horde. It also had nothing to do with read-only calendars. It's completely unrelated to the issue described in this bug. The problem with this bug is that you can't even *press* the dismiss or snooze buttons. It has nothing to do with the event firing or not, or how it's stored on the server. It's equally applicable to a locally stored calendar that had no write permissions.
Flags: wanted-calendar1.0?
Flags: tb-integration?
Flags: blocking-calendar1.0?
Is the any chance for this one to get fixed in 1.0 / Thunderbird 3 ?
Given the amount of code changes needed for this feature I don't think its advisable to do this in the 1.0 timeframe. Sorry.
Flags: wanted-calendar1.0?
Flags: tb-integration?
Flags: blocking-calendar1.0?
This bug makes read-only calendars completely unusable if alarms are enabled. I suggest to disable the alarm option (gray out) until this can be fixed. Otherwise this will lead to very bad user experience IMHO. Many home and small office users will run into this because of bug 329570 (datalos relnote) which enforces using read-only calendars when sharing calendar files on multiple machines on any LAN.
I agree its not ideal. Would you be interested in writing code to disable the alarm option for readonly calendars? I though it was already this way, but I could be wrong.
(In reply to comment #34) You can switch alarms on and off for each calendar. If you don't want to see alarms from a read-only calendar just tick the corresponding checkbox in the calendars properties dialog.
(In reply to comment #35) Hmm, I still use lightning nightly 2009-01-15 because this seems to be the latest one working on TB3.0b1. Maybe I'll find some time later to try the newest stuff or even look into hacking mozilla.
I have run into the same problem subscribing to Google calendars via Caldav where I am the owner of the calendar. The alarms continue to fire unless I turn off the alarm feature for that calendar. In reading this bug, along with 354883 and 422897 I get the feeling these are all the same problem, the underlying method used by the calendar application to determine whether or not to fire an alarm. A shared calendar via Caldav appears to be treated the same as a read-only calendar, where the calendar application requires write access to record dismissal information for the alarm for a specific event. With a shared calendar, that information should only be stored locally and never sent back to the server as it would effect other shared users. Ideally we should add an entirely separate case to handle a calendar that does not have write access and store that information separately from the normal calendar data. This is the whole reason I was even interested in using lightning (the problem has occurring in both Lightning and Sunbird on a Windows XP machine with multiple CalDav calendars hosted at Google) and now I need to decide to spend the time to fix this or look at other options. Anyone interested in tackling this?
(In reply to comment #19) > (In reply to comment #18) > > So the issue is obviously then that the RFC to which you're referring isn't > > wide enough in scope to include "read-only" calendars (I don't know I haven't > > read the RFC). > The RFC being referred to is rfc2445 and is about calendar. Alarms and how they > should be dismissed might be a shortcoming, there is the rfc2445bis draft, I'm > not sure there is much new things regarding alarms. Many applications build on > local databases. From the RFC: "This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet." It's just a data exchange format - not a calendar program design document. Designing a program around RFC2445 would be a huge mistake. I'm experiencing the same problems using Sunbird with remote read-only calendars. It should be clear that this problem needs to be addressed - considering the number of users who have reported on it and commented on it. I would be willing to take a stab at fixing it, if there was agreement in the Mozilla community that dismissing an alarm on a read-only calendar only dismisses the alarm in the local client.
Is the same behavior expected if an internet calendar is set up for read/write, but unavailable because of a network error?
(In reply to comment #19) > We have already been thinking of a local database for snoozing/dismissing > alarms on readonly calendars and also including other data. To do this in a > conceptually complete way, its not as simple as it may seem. It would probably > be best if this database would not only be able to save alarms, but also > arbitrary other data (i.e letting you add description to substitute for notes > on a work calendar). I was thinking a sort of "ICS overlay", that might not > contain valid ICS events, but something similar that holds all data that cannot > be saved on the readonly calendar. That sounds like a good approach. One difference though - since some of the commenters have indicated they want to share an iCalendar, Mozilla should strip out the client-specific overlaid data before writing the file. Otherwise, you'll end up with the multi-user issues described here.
At the very least, just force alarms to be disabled on read-only calendars. Having read-only calendars unusuable seems like a 1.0 block to me. By disabling alarms you at least make them somewhat usable.
Flags: blocking-calendar1.0?
If you don't want to see reminders for read-only calendars just disable the Show Alarms checkbox at the same moment you enable the Read-only checkbox.
> By disabling alarms you at least make them somewhat usable. IMHO this would make sunbird quite unusable in certain settings when you have to deal with multiple calendars while making sure not to modify them. The capability to synchronize calendar files (some sort of automatic one-way synchronization would suffice, i.e., the integration of an external calendar while coping with moved/modified events etc.) would seem to be a viable alternative for me. (At present, I don't use sunbird so I don't know if this possible with the current version.)
(In reply to comment #44) > If you don't want to see reminders for read-only calendars just disable the > Show Alarms checkbox at the same moment you enable the Read-only checkbox. Who said we don't want to see the reminders? Thats the whole point. Example. A calendar that has an event setup for 10:00pm monday reminding the buying staff that there is a meeting. We want all of the buyers (who subscribe to that calendar) to see that reminder, but we don't want one person to be able to dismiss it and thus turn off that reminder for everyone else.
er sorry, I made that first post a long time ago. You were discussing the "at the very least disable the alarms on read-only calendars" I think this should be put in before 1.0 release as a bandaide until a REAL solution is found. But yes you could just turn off alarms when you setup the calendar. Sorry. My apologies.
(In reply to comment #45) > > By disabling alarms you at least make them somewhat usable. > IMHO this would make sunbird quite unusable in certain settings when you have > to deal with multiple calendars while making sure not to modify them. The > capability to synchronize calendar files (some sort of automatic one-way > synchronization would suffice, i.e., the integration of an external calendar > while coping with moved/modified events etc.) would seem to be a viable > alternative for me. (At present, I don't use sunbird so I don't know if this > possible with the current version.) Yes, it seems like the idea of having a "local" copy of read-only calendars seems like the start of a real solution, but I don't think that looks like it will be done by the time 1.0 is released. All I'm saying is that I personally feel having an error message (can't write to calendar) pop-up on EVERY event with an alarm every time you startup sunbird/lightning seems like a 1.0 block to me.
Just ran into this. IMHO "show alarms" should default to off on "read-only" ical calendars at least. If the user chooses to them on (not sure it should be allowed), they should be told they won't be able to dismiss the alarm dialog box. I think the current situation (not being able to dismiss them), makes Lightning harder to use for many users. I don't see a problem forcing no-alarms, but some commenter think it should stay. So let it stay, but with a stern warning. At least this bug should be marked confirmed.
Why not copy the remote calendar item into a hidden shadow copy in the local calendar and setting there the snooze time and dismiss flag if the update of the remote calendar failed?
Come on Mozilla!!! This bug has been ignored by you for FIVE YEARS now! (It's not even confirmed or assigned to anyone.) And this is a significant usability issue, not to mention a clear bug when you display a button which is enabled yet does **** all... Less talking and more action please!
@Pepijn: As you're an experienced java-programmer/consultant/architect/designer yourself can we invite you to propose a patch? As you probably know there's no paid people working on Lightning, if you didn't know may I direct you to the weblog: http://weblogs.mozillazine.org/calendar/ and http://www.mozilla.org/projects/calendar/help.html
@Bas: please don't hide behind that old canard. The fact that the people working on Lightning aren't paid doesn't mean that they therefore have no obligation to fix problems. By your logic, no bug in Lightning would ever have to be fixed, and no one could complain about it because hey, it's free! *At the very least*, the bug could be acknowledged, and the non-functional button disabled. That would take all of five minutes for someone with actual experience with the code. Ten minutes more and the application would have some kind of warning about this issue, and/or disable the alarm notifications by default for read-only calendars. *For someone with experience with the code* that is. I.e., a Lightning developer, not a Java developer with zero experience with the code for Lightning or the API's of Thunderbird. Having said that, if someone can give me a crash course in the Lightning code, I'm perfectly willing to put my money where my mouth is and give it a shot. I'm not sure it would do much good though, since the problem here seems to be that no one can agree about fixing this in the first place.
This bug was confirmed 2006-11-04 17:05:47, we are very well aware of it. I'm sorry noone has decided to fix this bug yet, but as Lightning is a community project, I cannot obligate anyone to fix this bug. To fix this bug I would prefer a complete solution, that is why I haven't prioritized this bug myself. The full solution requires a lot of conceptual driving I don't have time for at the moment (this means either a full ics-overlay engine with synchronization mechanisms, or an intermediate solution like an extra database for dismissing alarms). The workaround you talk about should be a bit easier, but there will still be edge cases that cannot be fixed. Assuming you have succeeded building calendar (See [1]), the code change should probably happen in two places: You need to modify the alarm service [2]. It would make most sense to not fire alarms for items in the past if the calendar is readonly (check with item.calendar.readOnly in the addAlarmsForItem function). For items in the future, a timer instance is created (already happens, addTimer method) which fires the alarm. Regarding the snooze functionality, right now it relies on setting a property on the item. This is not possible obviously, so if the calendar is still readonly in the snoozeAlarm function then all that we can do is add another timer. If the app is restarted inbetween, the snooze will be lost and the user might miss an alarm. In the dismissAlarm function, I believe nothing needs to be done other than ignoring the call when the calendar is readOnly. Needs testing though. Another edge case, if the calendar is readonly and contains a snooze time property, this cannot be removed during dismissAlarm. As soon as the calendar is refreshed, the snoozed alarm is fired again. If needed, you can find the interface description for calendar objects here [3]. I hope this is enough to get you started, meet me on irc.mozilla.org, channel #calendar if you have any further questions (or comment here). When you are done with your work, attach the patch here and set review? to me (typing :Fallen is sufficient). Thanks for looking into this! [1] https://developer.mozilla.org/En/Simple_Thunderbird_build#Building_Thunderbird_and_Lightning [2] http://mxr.mozilla.org/comm-central/source/calendar/base/src/calAlarmService.js [3] http://mxr.mozilla.org/comm-central/source/calendar/base/public/
Wouldn't defaulting "show alarms" to off for "read only" calendars be a quick short term solution? The non-functional dismiss button should also be inactive if the only alarm is in a read-only calendar. Since you can't dismiss the alarm, it's probably also good idea to force "show alarms" to off, but at least one poster in this thread had a problem with that solution. They can be served by an advanced setting "allow alarms on read-only calendars". Long term, you can provide a way to allow alarm processing for read-only calendars. That's a feature. Not being able to dismiss an alarm is a bug. Robert
I like Philipp's suggestion of not showing reminders for alarms that are in the past for read-only calendars. That way, you could dismiss them by just closing them, and they should not recur, without having to save any state. Currently the calendar is only set to read-only after the first time updating it fails. Does anyone know whether iCalendar remote calendars can ever be writeable? If not then such calendars could be made read-only upon creation. If not then perhaps the code could do a check to see whether the calendar is writeable when it is first created. I'm looking into it.
Readonly calendars may not always be readonly. There are two cases here: * The calendar is server-side readonly, and/or the user has set the readonly checkmark. This can be relieved by the fix I described above. Note this may also mean the server allows writing, but the user does not wish to change things by accident and has decided to mark the calendar readonly. He or she may change the check- mark any time to regain read-write access, this usually causes a refresh. * The calendar is not marked readonly, but the server is having temporary issues This is a bit more tricky and should be solved in a different bug, or with the full sync solution. This situation transforms into the first case as soon as the calendar is marked as readonly (with the lock icon). I would not rely on a calendar always being readonly or not readonly, but try to adapt to the situation. Note also that the ability for the app to go offline might also affect this whole situation. If the user is offline, then only calendars that have the experimental cache enabled are available, these are then automatically readonly. If the above fix is implemented, then the user will need to dismiss alarms twice: once when he does so for the "read only" offline calendar, and then again when he goes online, the calendar refreshes (and is read-write) and due to the missing lastAck property in the item the alarm is signaled again. This is still better than the current situation though.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
The simple solution is easy enough to implement that it warrants blocking 1.0. It will greatly improve user experience.
Flags: blocking-calendar1.0? → blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
How disappointing! The UI for this quickly gets complicated. Removing the "Snooze" button from the widgets is easy, but what should we do with the "snooze all for" button? If there are only readonly alarms, then we can just disable/hide the snooze all for button, but if there are mixed alarms the user might expect even the readonly alarms to be snoozed. The only thing I can think of is add an explaining text that since there are readonly alarms, they will not get snoozed when pressing that button, but I don't consider that good UI style. Suggestions?
Hi Philipp, Just a development suggestion: The idea of Lightning modifying the calendar for alarms should change. An alarms database should be created and any new alarms or snoozing of alarms should be saved in that database. The first key would be the ID of the calendar and a second key would be the ID of the calendar event. Lightning would only have to poll one database for any alarm across any calendar (local or remote, read-only or not). I'm not familiar with the Lightning codebase so I'm not sure if this is feasible or not. It's just an abstract idea. Regarding dismisses: Dismisses should not be a recorded event. Why record them?
Michael, I am quite aware that this would better solve this issue, but its far more work than whats planned at the moment. We want to get 1.0 out of the door and avoid too much high-risk regressions. The idea behind saving the snooze/dismiss information on the calendar is that you only have to dismiss the alarm on one client, not on every client you use.
(In reply to comment #66) > Michael, I am quite aware that this would better solve this issue, but its > far more work than whats planned at the moment. We want to get 1.0 out of > the door and avoid too much high-risk regressions. OK. Understandable. Back to comment 64: I've thought of a couple solutions but I have no strong feelings about either one of them. Could the "Snooze all" button (in mixed cases) ignore writing to read-only events? The alarm window would then disappear. I think it would make most people happy. They just don't like seeing error windows or the window not closing. If the only alarms are for read-only calendars then the "Snooze all" button should change to "Close" as some window managers these days are removing buttons (Gnome 3). Another solution I can think of would have separate UI areas for read-only and read-write calendar alarms. You could hide one or the other area if there are no read-only alarms and vice versa. Then it would be clear that "Snooze for all" is for read-write alarms. The read-only alarms could have a "Close" button in place of "Snooze for all". > > The idea behind saving the snooze/dismiss information on the calendar is > that you only have to dismiss the alarm on one client, not on every client > you use. If your system date is past the alarm date and you open your calendar I wouldn't expect to see an alarm that doesn't matter to me any more. This should change. If people insist to see old alarms (*eye-roll*) then it needs to become a configuration option to control whether old alarms are shown or not.
(In reply to comment #67) > If your system date is past the alarm date and you open your calendar I > wouldn't expect to see an alarm that doesn't matter to me any more. This > should change. If people insist to see old alarms (*eye-roll*) then it needs > to become a configuration option to control whether old alarms are shown or > not. Check out the "show missed" options in the preferences.
Assignee: bugzilla → philipp
Unless it turns out to be unreasonable, we'll try to take this for the next release
Whiteboard: [not needed beta][no l10n impact] → [needed beta][no l10n impact]
Sorry, given the release is so close its unreasonable to take this. I'll see if this can go in for a subsequent release though (with string changes!)
Flags: blocking-calendar1.0+
Whiteboard: [needed beta][no l10n impact]
This bug has been around since 2006 and I still experience it with Lightning 1.4 on Thunderbird 12. My calendar had become read-only (due to some network error?), and I was not able to do other change to the calendar until I re-started Thunderbird to recover from the error state putting the calendar to read-only. Very bad user experience. In any case, if dismiss or snooze fails for whatever reason, a to-the-point info should be given to the user (e.g., "write to calendar failed") rather than just doing nothing and letting the user wonder why there is no effect. At least this info should not take the next 5.5 years to get implemented.
The solution really requires two changes. First, there has to be a way to make the notification go away! Second, a per-calendar option to ignore overdue notifications would avoid all the old ones time after time. Turning off notifications isn't a viable solution, it makes a department calendar pretty useless. Given the memory use of the application it seems reasonable to save DISMISS in memory, assuming that overdue notifications could be skipped. Perhaps a "stale date" config option, to ignore events more than N time overdue.
We're in 2013 and this is still buggy...
Although Lightning is (to me) the easiest calendar program to use and in all other aspects seems to work as intended, if it can't be used with group and department schedules it really isn't usable in most cases for more than personal use. That would be a shame, not only for the users, but for the developers who have given us this otherwise best of class tool. Perhaps someone in the support team could at least give us some information on why it takes seven years to fix this, and if it can't or won't be fixed, at least users would know that they should stop waiting for a fix.
(In reply to Bill Davidsen from comment #77) > Perhaps someone in the support team could at least give us some information > on why it takes seven years to fix this, and if it can't or won't be fixed, > at least users would know that they should stop waiting for a fix. Bill, please read comment 59. Also, comment 62, comment 64, comment 66. The Lightning team is not a big team of developers, its a small handful of people doing this in their free time, after work, between wife and kids. There is much to do, and sometimes seemingly important bugs just don't get any love because the other bugs are either more important, quicker to solve or frankly just more fun. When I fix this bug, I want to do it right and not hack in something that might fix it, but be either a maintenance nightmare or silently break in a few releases. If you want to try the patch I have attached, go ahead. I'm sorry I can't support applying it though.
Comment 66 shows that we have not adequately communicated the desired use of a shared read-only calendar, If an item has an alarm, we do NOT want on person clicking DISMISS as they leave for a meeting to kill the alarm for everyone, nor do we want one person on a call to hit SLEEP and make everyone else late. These must be client side in order to make the shared calendar useful to the group, and still allow users to process the reminders in a useful way. If that means that a person who has chosen a workflow which has the same calendar in multiple places will have to DISMISS or SLEEP in multiple places, so be it, that's a user choice. My feeling is that it is better to have users control their workflow than to put one policy on the server, however well chosen the policy might be.
(In reply to Bill Davidsen from comment #79) > Comment 66 shows that we have not adequately communicated the desired use of > a shared read-only calendar, If an item has an alarm, we do NOT want on > person clicking DISMISS as they leave for a meeting to kill the alarm for > everyone, nor do we want one person on a call to hit SLEEP and make everyone > else late. These must be client side in order to make the shared calendar > useful to the group, and still allow users to process the reminders in a > useful way. This is just the way we have been handling alarms, also on writable calendars. I understand the need for keeping this local, but this is really a different bug (that doesn't make it lesser in any way though).
I think you underestimate how much of a showstopper this bug is. It effectively makes Lightning useless for many people. I understand the desire to create a proper solution but if that failed for 7 years due to lack of motivation or resources, maybe it is time to escalate the issue by making it a release blocker or, god forbit, introducing a setting that allows people to band-aid it. The project lead, if there is one, can wait until some new coder comes in and fixes this issue, but I think it is much better to focus the existing developer's attention on it by setting its priority higher and making it a blocker for future releases. /rant
See Also: → 859399
Can I also add my 2 cents worth. I would prefer my machine to show missed alarms, unless I have dismissed them under my account (on any machine I use), but yes I see that having others dismiss my reminder on a shared calendar is undesirable. However, I have been using lightning for a number of years (since 2006ish), including sharing calendar accounts, but have only encountered this as a problem with the latest release (Thunderbird 15.0, Lightning 1.7 under ubuntu/linux). Without this working, it becomes less of a usable application for me and I may reluctantly have to source something else. Bill Davidsen's solution (comment 75) seems to be the best option here.
@82: This functionality has nothing to do with Lightning imho but has every thing to do with the server-software you use. You want some kind of user-control, Lightning already has this with caldav-servers...
(In reply to Bas van den Bosch from comment #83) > @82: This functionality has nothing to do with Lightning imho but has every > thing to do with the server-software you use. You want some kind of > user-control, Lightning already has this with caldav-servers... I may have misunderstood the issue then. I am using caldav-servers and mostly the problem occurs with read/write access calendars. However, I was running an incompatible version of lightning (1.7) and have just updated (to 1.8). Please ignore my previous comment.
I've noticed the that reminders cannot be dismissed until I have at least reminders in the dialog popup. 1-2 reminder entries can each be snoozed and/or dismissed individually or as a group, but after I reach 3 reminders in the list any action either leaves the dialog up or dismisses the dialog, only to have it appear again - with the same, 3 or more entries - a few seconds later. My latest bought with this issue is occurring with 3 reminders from a r/w Google Calendar.
(Good gravy, so sorry for the typos/editing errors in my prior entry - no idea how I messed things up the badly)
Depends on: 861594
I'm not going to be working on this issue until bug 861594 is fixed. Given previous discussion, please don't take this as an invitation to rant about how sad it is that this bug is not fixed yet and no one put a hack in place to work around it.
Assignee: philipp → nobody
Status: ASSIGNED → NEW
Hi, Philipp. Thanks for letting us know. Being involved in other open source development I understand that some things take time. It's good that this is still on the radar and that you have intentions of getting it in.
Won't fix.
Attached patch WiP - v1 (obsolete) — — Splinter Review
Just found this patch locally and thought I'd attach it so it doesn't get lost. You can give it a test run, but its likely that its unfinished.
Thank you Philipp for the patch. I tried it and it works very nicely on Lightning 3.3. It does exactly what I needed most, getting rid of reminders from r/o calendars. Since I did not want to go through the hassle of recompiling the whole extension (and TB) for this, I simply adapted the patch to work on the appropriate files in the install directory of the extension in my profile. I know that's ugly, but works - sure only till the next update, but repeating it then is easy. So I wanted to let others know this works and offer this slightly adapted version (only file path and line number changes) which can be easily applied like this: $ patch -b -i alarm-readonly-installed.diff -p 0 -d ~/.thunderbird/YOUR_PROFILE/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}
Just wanted to chime in here to say that the patch 8465571 works nicely here with Lightning 3.3.1/Thunderbird 31.2. Thanks for this! This issue was incredibly obnoxious. I'm also using DavMail, so error pop-ups all over the place with this one. Works perfectly now. The other issue seems to be that with Read-Only, there's no way to set a local reminder that can also be dismissed locally. Otherwise, it makes sense that dismissing a notification in Thunderbird keeps the notification from continuing to buzz on my phone, for instance. For a read-only calendar, disabling notifications seems like a fair next step until a local notification setup exists. Without doing this, my read-only calendar isn't worth syncing due to the constant barage of dings and pop-ups. Thanks again for the great work on the patch!
The patch works, at least for individual items. The 'Dismiss all' button is not patched. Anyway, thanks so much! This has saved the day here bud.
Despite not having changed anything in Tbird for quite some time, this problem appeared yesterday. I now have a reminder that can't be dismissed. I upgraded to version 38.3.0 and it's still happening.
I have version 38.3.0 also and have two reminders that cannot be dismissed and closing the window only brings it back later. Let me be more clear, I only have two reminders and I cannot dismiss them and they keep coming back.
My apologies. TBird is no longer syncing with google properly but I had loaded two events into the TBird calendar. Somehow the .ics file they were in was flagged as read only. I deleted the file and all is right with the world.
Attached file thunderbird_alarm_ro_patch.zip (obsolete) —
I've created a very simple helper script for Linux to apply the patch. This makes it easier to apply the patch after every Thunderbird update (just a single click) and is perhaps also useful for novice users who find this bug and don't know what to do exactly. I'm using this script myself for quite a while now to patch every new Thunderbird version that's released.
Attached file thunderbird_alarm_ro_patch.zip (obsolete) —
Hey, more than 10 years of this bug. Great :-) I'm patching every new version on every machine at home and at work until someone finally shows mercy with us mere mortals and integrates this patch into new Thunderbird releases... Find attached a new version of the patch that also works (tested on Ubuntu) when you have installed Lightning from APT (this is why it asks for the root password). Enjoy!
Attachment #8770181 - Attachment is obsolete: true
I know this isn't overly helpful, but the issue still exists in the latest Thunderbird + Lightning + Google Calendar. I have checked the error logs and clearly it is trying to write the read-only Google Calendar which results in a 403. I think this is probably a common use-case, since Google Calendar supports events such as birthdays, holidays or you can import external events such as Facebook events, which are all handled as read-only. (This is clearly well recognized from the lock icons next to the calendars.) So currently it is not possible to have alarms for these calendars. I think that even the above patch could be an acceptable workaround for the time being (since it is unlikely that the local database solution will be happening seeing how old this bug is).
this bug still exists in Thunderbird 52. Obviously a ics served over http is not writable, whoever thought it would be? I've got a dozen unclosable reminders for events in the past. Time to check out Evolution.
Version 52.0.1 (32-bit). I have this same problem. Have had for over 10 years. For some reason the database gets put into read only state all by itself. I don't put it into read only. This happens after many minutes after loading the Thunderbird app. I can delete or dismiss or edit an event if I do so immediately after loading Thunderbird.
Here is my example -- trying to "dismiss" an event for a company-wide meeting two weeks ago: Error: [calGoogleCalendar] Modifying item 4th Floor - All Hands Friday failed:2147500037: { "error": { "errors": [ { "domain": "global", "reason": "forbidden", "message": "Forbidden" } ], "code": 403, "message": "Forbidden" } } Why is Lightning trying to even talk to the server to "modify" this one? Of course, it has no permissions to do that -- all I ask is that the event be removed from MY OWN list of reminders (which it really ought to do automatically, when the scheduled event time moves into the past). (BTW, I'm using Seamonkey-2.46 with built-in Lightning-5.1 on FreeBSD.)
That is a message from the Provider for Google Calendar. Note that the Google APIs have a notion of private properties even for readonly events. I guess the way I am setting them does not always work as expected, I know there is a certain shortcut involved.
Thanks for the clarification, Philipp. I still do not understand, why an event can not be removed from the list of reminders on _my_ screen, unless it is also updated one a remote server. To clarify, I do understand, why the attempt to update it is made -- but the local removal should succeed independent of that and also regardless of which back-end is charge of the remote...
Just the reason this bug is still open :) We still need to store it somewhere, and until now we don't have a way to do so because it is usually saved as a property on the item, which means a remote modification. We hope to find time for this bug again soon!
I'm having the same problem, and after reading this I still cannot understand how to fix it, I cannot apply the patch either, since I use windows, any help?
I tried with ics, but I didn't like the implementation, it isn't working as smoothly as provider for google calendar does, I even tried a suggestion I found: "remove google calendar account -> unistall provider & lightning -> restart -> install provider & lightning -> google calendar account again", it didn't work either, so, if I understand correctly, this is a bug running for 11 years now?? is this some sort of record? maybe it should be noted in Guinness book, I've never heard of a bug running for double-digit years! I understand the nature of the problem, thunderbird tries to change some property to a read-only calendar and obviously fails, but why dismissing an event would require a change on the calendar? In order to remember that for the reminder? Couldn't/Shouldn't this sort of information be stored locally? anyway, any suggestions?
Hey! Can I work on this?
Assignee: nobody → makemyday
Blocks: ltn62
Status: NEW → ASSIGNED
Whiteboard: [has l10n impact]
Patch with the dialog behaviour as discussed on irc (except of exchanging the labels of the 'snooze all for' button). Please check the strings whether they need re-phrasing. The explaining string for the error dialog will be available when clicking the 'details...' button.
Attachment #8348605 - Attachment is obsolete: true
Attachment #8465571 - Attachment is obsolete: true
Attachment #8800608 - Attachment is obsolete: true
Attachment #8939331 - Flags: review?(philipp)
Hello, I have reviewed the patch. If I get it right, it seems troubling that read only calendars will miss alarms if Lightning is not running at the alarm's time. Other than that... Typo in the help message: expirience -> experience.
Philipp, I hope you didn't start the review, otherwise I apologize for the inconvenience. There has been a visual issue with the notificationbox in the previous version, which is fixed with this patch. I also fixed the mentioned typo and updated the string for the pref dialog to make the (modified) scope of showing missed alarms more obvious.
Attachment #8939331 - Attachment is obsolete: true
Attachment #8939331 - Flags: review?(philipp)
Attachment #8940504 - Flags: review?(philipp)
(In reply to Speeder from comment #115) > I have reviewed the patch. If I get it right, it seems troubling that read > only calendars will miss alarms if Lightning is not running at the alarm's > time. Thanks for looking into it. Yes you're right, this patch is limiting the scope of the feature to show missed reminders. But this is intended to adjust it to the current capabilities and in turn improve the usability for these working bits, so that what we have working feature to the advertised extend. Supporting also missed reminders for read-only calendars would require a larger change, for which we don't have the capacity in a foreseeable future.
I've reached out to the writer of #c118 about their comment. If you've got further concerns, please email me.
(In reply to Mike Hoye [:mhoye] from comment #119) > I've reached out to the writer of #c118 about their comment. If you've got > further concerns, please email me. Thank you for the suicide hotline numbers. :) I hope I didn't scared you about the sentence "I want to kill myself". In the context of my comment, I mean, that I get angry about the every time occurring reminders. :) They also steal the window focus, writing code is a pain with this bug. :)
Comment on attachment 8940504 [details] [diff] [review] AllowDismissingAlarmsForReadonlyCalendars-V2.diff Review of attachment 8940504 [details] [diff] [review]: ----------------------------------------------------------------- I haven't tested the patch in action, but the code looks fine to me. r=philipp ::: calendar/base/content/dialogs/calendar-alarm-dialog.js @@ +69,3 @@ > } > } > + widgets.forEach((widget) => { Can you just use for..of here? @@ +336,5 @@ > setupTitle(); > + closeIfEmpty(); > +} > + > +function doReadOnlyChecks() { Can you add a jsdoc header here? @@ +346,5 @@ > + countRO++; > + } > + } > + > + // we disable the button if there are only alarams for not-writable items typo alarams ::: calendar/locales/en-US/chrome/calendar/preferences/alarms.dtd @@ +17,5 @@ > <!ENTITY pref.calendar.alarms.sound.play.label "Play"> > <!ENTITY pref.calendar.alarms.sound.play.accessKey "P"> > <!ENTITY pref.showalarmbox "Show the reminder dialog"> > <!ENTITY pref.calendar.alarms.showAlarmBox.accessKey "x"> > +<!ENTITY pref.missedalarms2 "Show missed reminders if calendars are writable"> What about "Show missed reminders for writable calendars" ?
Attachment #8940504 - Flags: review?(philipp) → review+
Updated patch with comments considered.
Attachment #8940504 - Attachment is obsolete: true
Attachment #8942522 - Flags: review+
Keywords: checkin-needed
Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/22fd03a810f7 Allow dismissing alarms for read-only calendars. r=philipp
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 6.1
No longer blocks: 541376
Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/8764bc6727ef Follow-up: fix typo in localization note. rs=typo-fix
Thanks, Axel. I'm not crazy to trigger a full build for a typo fix in a comment, there's been an M-C merge since the last C-C push and I like to trigger a build after every merge.

I hate to say it, but it looks like this bug has resurfaced. I had somehow set one of my calendars to read-only, and today an alarm came up that I couldn't get rid of. When I hit 'dismiss', a dialog box came up asking whether I wanted to save my changes or discard them. Neither one made any difference; that save/discard dialog box kept coming up. Worse, it was modal, so I couldn't get to my email or the calendar in order to change it to non-read-only. I restarted TBird several times, but while I could do things for awhile, as soon as another calendar event came up, this non-stoppable one came up with it. I could dismiss the new one, but not the one from the read-only calendar--whenever I tried to do so, the save/discard dialog came up again. Finally after a re-start, I was able to change the read-only setting on that calendar before this event popped up again, and then delete the event.

I have my fingers crossed that it won't happen again.

TBird 78.8.1, 32-bit release on Windows 10 (64 bit)

See Also: → 1709055
See Also: → 1971160
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: