Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:126.96.36.199pre) Gecko/20070920 Calendar/0.7pre Dismiss single occurrence of repeating event dismisses all occurrences Steps To Reproduce: 1. Start Sunbird with a clean profile 2. Create a daily repeating event with alarm a few days in the past 3. In the alarm dialog dismiss just the first occurrence of the repeating event Actual Results: All occurrences are dismissed. Expected Results: It should be possible to dismiss or snooze each occurrence one by one. I'm pretty sure this worked before but need to find the regression range.
I don't expect this to be a regression since alarmLastAck has always been saved at the parent item.
I am not sure whether we should preserve those alarms, because the user has acknowledged the item dismissing any alarm. And after all, that's IMO the purpose of firing alarms. The alarm window is not meant to serve as an agenda or similar. IMO we should consult Christian's opinion here.
IMO, the alarms need to be preserved. Repeating alarms should act just like separate events. In my case, I want to know which of the events have been dismissed and which haven't. If the user wants to dismiss all of them, they can dismiss each one. Otherwise, there would be no way to treat them as separate events. Also, I use repeating events as reminders to do something that I have to do each week. For example, I have to check the salt in my water softener once each week. If I keep putting it off until the following week, I will then have two alarms. In that case, I want to dismiss only the earlier one, but I want the later one to stay until I've completed the task. If all are dismissed at once, I won't be reminded to complete the task.
(In reply to comment #3) Sorry, I can't follow you. Alarms are meant to catch your attention, but not for task planning.
I'm not sure what the distinction you're trying to make is, but the bug seems to occur for tasks too.
(In reply to comment #4) Alarms are meant to be what user want it to be, I want to dismiss one of the event I need to be able to do it... If I want to dismiss them all I use the "dismiss all" button not the single event dismiss one, like when having multiple "normal" (meaning unique) event/task.
Summary: Dismiss single occurrence of repeating event dismisses all occurrences → Dismiss alarm for single occurrence of repeating event dismisses alarm for all occurrences
It would be good to ahve a solution for this in 0.8
Flags: wanted-calendar0.8? → wanted-calendar0.8+
IMO it's ok how we currently handle it, see comment #2. However it would be nice if Christian could comment on the behavior. No priority => wanted0.8-.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
IMHO it was OK in 0.5 and earlier. If I want to dismiss all the alarms I press the dismiss all button. It has already happened that I wanted to dismiss all ones except the today's one because I hadn't finished that at that time. So please do revert it in 0.8 as it was earlier.
"Dismiss all alarms" dismisses all items that have an open alarm. That's not the same. I think what's misleading here is that people want to acknowledge the very same item more than once.
See, I'm just an ordinary user. I set up Sunbird to notify me each day at 18:00 to take my pill (it is actually white, neither red nor blue). I don't open Sunbird every day (I know it's too bad) so it happens that I get a handful of notifications to take the pills. Then I dismiss the ones I've already fulfiled and want to leave the actual on to be repeated after a snooze because at that time I can't take my pill. That was worked in 0.5 and is broken in 0.7. If I change my hat from user to an architect I'd like to mention that the different occurences of a repeated calendar entry are not the same items. They should be separate objects as they refer to separate events. One event happened yesterday, the other today. They are two connected but different entities with different life cycle, with different properties, with different editing capabilities (e.g. one event can be edited without affecting the others). Consequently the alarms should belong to these actual events one-by-one and not the parent event as a whole. Consequently alarms should be dismissable one-by-one.
Daniel Boelzle, You write: I think what's misleading here is that people want to acknowledge the very same item more than once. I have to agree with Mészáros Gyula. It's not that I want to acknowledge the very same item more than once, it's that when I create a repeating event or task, I don't consider them the "very same item" at all -- I consider each similar but entirely separate items that happen to be defined (and sometimes edited) at the same time. -Bri
Alarms are meant to catch your attention, not to serve as an agenda. IMHO it's even valid to replace outdated alarms of a recurring series with the latest alarm. BTW: W.r.t. 0.5 this is even no regression. IIRC if you dismiss a single alarm of a recurring series in 0.5, you won't get back the undismissed ones after application restart.
I think it is correct to continue to rise alarms for each occurrence, even if a previous occurrence got dismissed. A typical use case for me would be for example the Weekly Calendar Status Meeting. I personally like to be reminded each and every week, again and again, even if I've dismissed a reminder for one of the previous meetings.
(In reply to comment #15) The case you are mentioning is valid and working. But the discussed case here is: 1. You define a recurring event with alarm. 2. You get the first alarm, then the second, ..., but you *don't* dismiss a single one, i.e. you have multiple alarms referring to the same recurring event (though different occurrences, all but the latter one have been missed). 3. You are dismissing (acknowledging) any alarm referring to that recurring event. => All alarms corresponding to that event disappear from the alarm window (You'll of course get a new alarm for the next occurrence(s).)
Daniel, If alarms were only meant to catch your attention, they wouldn't have a "snooze" function at all. Alarms ARE meant to serve as an agenda. What is a calendar other than an agenda? If alarms aren't meant to serve as an agenda, aren't tasks meant to serve that purpose? Tasks seem to behave the same way. I view tasks as simply events that don't appear in the calendar because they don't have a set time that they occur (like mowing the lawn), but something like taking a pill at a particular time should go into the calendar. Aren't alarms supposed to serve as reminders for calendar events? If I am supposed to take my pill every day at 8:00am and happen to miss a day, two alarms pop up the following day as expected (one for the missed pill and one for the current day). Are you saying that I shouldn't get two alarms (one to let me know that I missed yesterday's pill and one to let me know about today's pill) and that they should act as though they are the same event? Let's say I want to skip the missed pill and snooze the other one for a half hour, why should dismissing the missed pill also dismiss the one I wanted to snooze? Let's say I'm taking a type of pill that requires me to "double up" the following day if I miss a day. If there is only a single alarm, I would never know that I missed a day. Can you give me an example where it would be desirable for recurring events/tasks to behave as if they are a single event/task? I'm not sure I understand how that would be useful at all. -Bri
It seems to me that the functionality that people are requesting in this bug would work better with recurring tasks (when they are fully implemented in Calendar) instead of with recurring events. For example, instead of keeping three reminders for three instances of an event, you could have three instances of a recurring task, each marked incomplete until you explicitly mark each instance as complete. IMO this would be more powerful and flexible than using reminders to simulate completion status. Bri wrote: > Can you give me an example where it would be desirable for recurring > events/tasks to behave as if they are a single event/task? If I have set three reminders per day, and I go on vacation for two weeks, I don't want to have to dismiss 42 reminders when I return. And I might not want to click the "Dismiss All" button either, because there might be some reminders for special one-time events which I want to snooze, etc. Regarding the example with pills, IMO taking a pill is a task, not an event. It seems to me that the main problem is that you want to be reminded to do the task at a specific time of day. I believe that there is a bug request somewhere that will allow tasks to have a reminder that's set to a specific time of day.
(In reply to comment #17) > If alarms were only meant to catch your attention, they wouldn't have a > "snooze" function at all. Alarms ARE meant to serve as an agenda. What is a > calendar other than an agenda? If alarms aren't meant to serve as an agenda, > aren't tasks meant to serve that purpose? Tasks seem to behave the same way. Yes, use a recurring task for that. It fits the calendar scheme. Each time you've taken a pill, you can mark one occurrence being complete. > I view tasks as simply events that don't appear in the calendar because they > don't have a set time that they occur (like mowing the lawn), but something > like taking a pill at a particular time should go into the calendar. Aren't > alarms supposed to serve as reminders for calendar events? Tasks are calendar items as events are. Yes, alarms are supposed to serve as reminders for calendar events. > If I am supposed to take my pill every day at 8:00am and happen to miss a day, > two alarms pop up the following day as expected (one for the missed pill and > one for the current day). Are you saying that I shouldn't get two alarms (one > to let me know that I missed yesterday's pill and one to let me know about > today's pill) and that they should act as though they are the same event? > Let's say I want to skip the missed pill and snooze the other one for a half > hour, why should dismissing the missed pill also dismiss the one I wanted to > snooze? Let's say I'm taking a type of pill that requires me to "double up" > the following day if I miss a day. If there is only a single alarm, I would > never know that I missed a day. Yes, IMO it's wrong to use/rely on alarms for that purpose, and again, this strikes you even in 0.5: after process restart your old (dangling) alarms are lost, because you've acknowledged the item's alarm. BTW another point why I wouldn't use alarms for your purpose: If you have another/different calendaring app on your calendar data (e.g. your mobile), you won't get what you want, because it doesn't know about our alarm acknowledging props (X-MOZ-LASTACK). So the only way I can recommend is to use plain VTODOS for your purpose. > Can you give me an example where it would be desirable for recurring > events/tasks to behave as if they are a single event/task? I'm not sure I > understand how that would be useful at all. Simply to let you know that an instance of that recurring item is about to happen. Brian, we definitely have different opinions on this. I think it's time to involve other people into this discussion. I may be biased by technical background, but I think tasks/VTODOs are what you should use.
Daniel, I agree that "Take a pill at 1800 each day" is a task, not an event and should be handled as such. However, a weekly project status meeting like our weekly confcall is surely an event and I'd like to add this as a recurring event into our app and get an alarm every week so that I don't forget to attend. I think that we should handle this. Do you agree?
I totally agree see comment #15 >> Can you give me an example where it would be desirable for recurring >> events/tasks to behave as if they are a single event/task? >If I have set three reminders per day, and I go on vacation for two weeks, I >don't want to have to dismiss 42 reminders when I return. And I might not want >to click the "Dismiss All" button either, because there might be some reminders >for special one-time events which I want to snooze, etc. I also agree to that. Maybe it makes sense to group reminders, with the same ID, which took place in the past, to one single item.
(In reply to comment #20) > However, a weekly project status meeting like our weekly confcall is surely an > event and I'd like to add this as a recurring event into our app and get an > alarm every week so that I don't forget to attend. > > I think that we should handle this. Do you agree? Simon, we (already) handle this correctly. That's not what we discuss. Please read comment #16.
(In reply to comment #19) > Yes, use a recurring task for that. It fits the calendar scheme. Each time > you've taken a pill, you can mark one occurrence being complete. I admit that I don't fully understand the difference between tasks and events (they seem to behave nearly the same to me, and I can't even see the conceptual difference). Is a meeting a task or an event? Is my son's bus arriving (I have to walk him home from the bus each day) a task or an event? I don't have a problem with using tasks for things that I need to be reminded of, but the last time I tested recurring tasks, dismissing one recurring task reminder dismissed all of them, just like with events. > Tasks are calendar items as events are. But they don't appear in the calendar, right? I suppose if I wanted a task to appear, I could enter a separate calendar event for it. > Brian, we definitely have different opinions on this. I think it's time to > involve other people into this discussion. I may be biased by technical > background, but I think tasks/VTODOs are what you should use. I agree, but I'm willing to accept your opinion on this as long as one or the other meets the purposes that have been suggested. One thing that would make tasks more useful (aside from fixing the bug that dismisses all recurring tasks when one is dismissed) is if there was an option to hide a task in the list until its start date (i.e. hide pending tasks) as you can hide completed tasks. That way the list would contain only those tasks that you have to do, and recurring tasks wouldn't constantly appear in the list.
(In reply to comment #21) > Maybe it makes sense to group reminders, with the same > ID, which took place in the past, to one single item. That would be okay (if it's like a tree with one parent and several children). On the other hand, if all reminders of a specific event disappear from the window when I dismiss one of them, then this behavior is sufficient for me.
(In reply to comment #18) > It seems to me that the functionality that people are requesting in this bug > would work better with recurring tasks (when they are fully implemented in > Calendar) instead of with recurring events. That's possible. Currently, I don't think tasks can do what others and myself are using the events for, so it's likely that if the tasks are modified to allow additional functionality I wouldn't have an objection at all. I believe that dismissing one recurring task currently dismisses all of them (although I haven't tested it recently). > If I have set three reminders per day, and I go on vacation for two weeks, I > don't want to have to dismiss 42 reminders when I return. And I might not want > to click the "Dismiss All" button either, because there might be some reminders > for special one-time events which I want to snooze, etc. I can see that. A "dismiss all recurrences" button (similar to the "edit all recurrences" option) would also work. As would snoozing those items that you want snoozed, then dismissing all. Which brings up another question: would snoozing one of the recurring events snooze all of them (or snooze the latest one and dismiss the rest)?
(In reply to comment #23) > Is my son's bus arriving (I > have to walk him home from the bus each day) a task or an event? That's a tough one. Maybe this helps: http://wiki.mozilla.org/Calendar:FAQ#What_is_the_difference_between_a_task_and_an_event.3F > but the last time I tested recurring tasks, dismissing one recurring task > reminder dismissed all of them, just like with events. I think that there will be a solution when Bug 373775 is implemented. You can vote for that bug. :) > > Tasks are calendar items as events are. > > But they don't appear in the calendar, right? I suppose if I wanted a task to > appear, I could enter a separate calendar event for it. They appear if you give them a start date and enable the menu item "Calendar > View > Show tasks in calendar". > One thing that would make tasks more useful [...] is if there > was an option to hide a task in the list > until its start date I think that this will be possible with Christian's design. Notice that there's a section for "Today" in the task list in the Today Pane: http://wiki.mozilla.org/Calendar:Mail_View_Integration > would snoozing one of the recurring events snooze all of them > (or snooze the latest one and dismiss the rest)? I don't know but I think that it should snooze the latest one and dismiss the rest.
Pete, Thanks for the info! I understand the difference between events and tasks a little better. It's still unclear to me why recurring events aren't considered separate events. I think this makes an assumption that subsequent recurring events must "replace" older events, but that's not always the case. Sometimes, you want snoozed events to "accumulate" -- to produce multiple separate events. At the very least, it is not desirable that dismissing a past recurring event dismisses a pending recurring event (as I think is the current behavior). Let's say that after returning from vacation, I get 4 reminders for weekly meetings: 3 that I've missed while on vacation, and 1 that's in an hour. Why would dismissing the reminder for a missed meeting also dismiss the reminder for the pending meeting? > If I have set three reminders per day, and I go on vacation for two weeks, I > don't want to have to dismiss 42 reminders when I return. And I might not want > to click the "Dismiss All" button either, because there might be some reminders > for special one-time events which I want to snooze, etc. I understand the convenience of being able to dismiss more than one reminder at a time, but that issue wouldn't be limited to just reminders for recurring events. If I go on vacation, I could have 42 completely unrelated reminders come up and have the exact same situation. Currently, the easiest way to handle it is to snooze those you want snoozed, then "dismiss all" for the rest. I'm just not sure that the confusion caused by making recurring events an exception to the general rule that the "dismiss" button only dismisses the reminder it's associated with is worth sometimes being able to dismiss multiple reminders at once. If it's important to group/dismiss multiple reminders, a new feature should be added to do that.
> I'm just not sure that the confusion caused by making recurring events an > exception to the general rule that the "dismiss" button only dismisses the > reminder it's associated with is worth sometimes being able to dismiss multiple > reminders at once. If it's important to group/dismiss multiple reminders, a > new feature should be added to do that. that's probably the whole point of this bug, I think one of the best solution I've seen is to group all the recurring event inside a group with a dismiss button for the group (which would dismiss all the occurrence of the event) and to keep the single dismiss button (that would really dismiss a single occurrence of the event), the dismiss all button being unchanged.
(In reply to comment #28) > that's probably the whole point of this bug, I think one of the best solution > I've seen is to group all the recurring event inside a group with a dismiss > button for the group (which would dismiss all the occurrence of the event) and > to keep the single dismiss button (that would really dismiss a single > occurrence of the event), the dismiss all button being unchanged. That would work, but still implies that they are separate events. If the recurring event is really only one event, it might make sense to automatically dismiss all but the last recurrence and have a single reminder tell you how many recurrences have triggered. It would be important to refer to it as "a recurring event" rather than "recurring events." Now, what happens when someone edits a single recurrence? Does it split off and become its own event, or does it stay part of the recurring event?
I think that another good solution for this requested functionality (in addition to using recurring tasks) will be available when Lightning/Sunbird can send email reminders. This way you can track the reminder of each instance of a recurring event in a mailbox. This would have the advantage that you can see the exact date/time when the reminder occurred, delete the obsolete ones, and automatically forward them to other people if you want. I think that you've made some great points, Bri, but I also think that there are better ways to achieve what you want.
Alarm Panel should have the following features and behavior. Snooze: 1. Snooze - Option to snooze all displayed alarms. 2. Snooze - Option to snooze only one or more of the displayed alarms - currently snoozing one alarm in an events or tasks list snoozes all or more than one of the displayed alarms. Now granted this may be an action to "snooze" multiple occurrences of a repeating task listing but this should not necessarily occur and if it "has" to snooze all events of a recurring events or tasks list - then the button or tab should be labelled as such in the user display. Current inference is that a user can elect to snooze only one of the displayed alarm events but calendar behavior does not match that alarm action. Possibly this is more of a feature request but related to the snooze feature and alarm status - a user should be able to access the alarm list - that is to view the current active or running list of snoozed alarms. Ideally to review also dismissed alarms. As I wrote this reply I had previously opened Sunbird 0.7 - triggered an alarms list and selected a "snooze" interval of 1 minute for one of the listed alarms and a "snooze" interval of 60 minutes for another of the listed alarms (these pertained to a task event). However after at least 10 minutes no alarm has triggered for the "snoozed" alarm. As queried in this thread: "Now, what happens when someone edits a single recurrence? Does it split off and become its own event, or does it stay part of the recurring event?" Appears that the latter may be the correct answer here - unfortunately. I suspect that "other than a bug" this has to do with the fact that multiple instances of a recurring alarm are not "considered" as separate events by Sunbird - even though they are "displayed" as such in the alarm panel. Snooze or Dismiss should be individually contollable actions for any task or event shown on alarm list - otherwise why show them as individual events or suggest to the user that these can be treated as such? Granted, Snooze or Dismiss should also be broadly controllable actions for all tasks or all events shown on an alarm list. Basically to snooze or dismiss alarms should be cafeteria-style for the user. Snoozed or Dismissed alarms should also be accessible to user to review or "reset" - ergo if user was to snooze a task for 60 minutes - then complete the task 10 minutes later - they should be able to "recall" the list of snoozed tasks to "clear" that task. Behavior as outline or experienced as above makes sense to me but have not been able to "test" Sunbird as extensively as I would like to - simply because it is not yet "useful" enough or in my case does not follow as "logically" in behavior and feature access that I envision it should. As a point of information I currently rely on features using the calendar and e-mail notice features of MyWay.com - mail - calendar - notepad system and then stand alone program - Note Wonder to track - remind - and alert for tasks - individual - tasks - recurring and events. Quite simply having to deal with 10's to several hundred events - tasks and e-mail reminders on a daily basis - I can certainly test or suggest features to consider for incorporation but appears there simply are not enough developers involved and unfortunately is not something I can contribute to in that regard. Even the "help" menu list of Sunbird does not contain links to report bugs - suggest features - or access forums for help and background. Logically these would appear in the earliest all subsequent versions.
OS: Windows 2000 → All
Hardware: PC → All
Version: Trunk → unspecified
Agree with Bri and with Christian. The scenario I have is defining one recurring event for classes (MWF@9:30, let's say), one recurring event for research meetings (M@4:30pm), one for seminars (Tth@3:30pm), etc. etc. And I'm likely to be busy working on some project or research, and need a reminder for each class/meeting/seminar. Each event recurs for an entire semester. Dismissing one reminder shouldn't dismiss them for the whole term -- that'd be useless after two days...
Ben, I don't really see your problem since you will get ongoing alarms for events that appear in the future; referring to comment #16 here.
That's precisely my point. I'm *not* getting alarms for events in the future, once I've dismissed an alarm for a past or current instance. The precise steps I've taken are: 1. Create a Google calendar (I'm using the latest Lightning 0.8pre and GData 0.4pre). I created a fresh calendar for this, to make sure it wasn't some weird misconfiguration somehow. 2. Create a recurring event, every Monday at 4:30, let's say, starting a few weeks ago and continuing for another month or two. (I start it in the past for example purposes) 3. In Lightning, I double-click an event, and edit "All Instances". I set an alarm for 5 min before. 4. All instances of the event show an alarm icon -- hooray, it worked :) 5. All past and current instances of the alarm pop up at once, which is reasonable. I dismiss just one of them -- any one of them. 6. All alarms in the alarm window are dismissed. 7. *All alarms in the future are dismissed too.* The alarm icon is gone -- no big deal; I know that's a separate bug. But when I go to edit the series of events again, the Reminder has been wiped clear. I'd filed this separately as bug 414981, but was pointed to this one by Stefan. I'm not sure why (maybe it's a combination of Lightning+GData) I'm getting this behavior, but it doesn't work as expected :-\
Note, that the gdata provider specifically has problem with alarms for recurring events! I have found no good way to retrieve all X-Props that are lastack related. Therefore, alarms for occurrences are quite questionable there.
Philipp, I don't fully understand what the issues are, but I can try to take a look and see if I can help. I'm looking at the code in calGoogleUtils.js, and what I gather from your comment is, you're using gd:extendedData properties to store and retrieve X-MOZ-LASTACK and X-MOZ-SNOOZE-TIME values, correct? And these correspond to the most-recent alarm you've acknowledged and the time you last snoozed an alarm? What "other X-Props" are lastack-related, and is it a failing of the GData API that you can't manipulate them properly? Looking at how you handle single-instance versus recurring events, the recurring case never checks gd::when or gd::reminder -- according to the google docs about its API, that's because they're not part of a gd::recurrence? I have a few other questions and maybe some ideas, but I don't know if this bug is the right forum for them, and could take this discussion offline... HTH
Ben, thanks for looking into this. I just created bug 415742 for related GDATA problems.
Some user perspective: The reson for this to be considered a bug in the first place is the Dismiss button appears for every single occurence of the task, and unless *clearly* stated otherwize the user will expect it to dismiss that single occurence. There are several workarounds, some already proposed so I'm going for the easy ones: 1. Add configuration options to switch between both (dismiss same, dismiss one) behaviors. 2. Relabel the dismiss button to the short of "Dismiss all current and previous alarms for this recurring task/event". 3. Let the user know what will actually happen when the Dismiss button is used. This is the most controversial because there must be a way to make sure the user knows about this before using the feature. Please consider the word "bug" translates to "not working as expected" for most users. I was considering this a bug until I read the comments here. Now I know it's not a bug but a specific behavior... but most (potential) users won't. So writing a SUMO article about the subject is a good place to start. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20080917 Sunbird/0.9
My proposal: Dismissing a specific event should dismiss also all older alarms of this event but not the newer ones especially not an open alarm for an event in the future. This would offer the possibility to clean up the alarm list without additional buttons - for instance after a one month vacation resulting in a lot of open daily alarms - without loosing the possibility to snooze the newest alarm somewhat closer to the beginning of the event. From the viewpoint of a simple user like me the actual behavier is not a feature but clearly a bug: Dismissing explicitly older alarms is not expected to destroy the possibility to snooze the newest alarm.
Wow, quite a bit of discussion on this bug. I would appreciate if someone could sum up all arguments into a short comment. I personally favor Jonatan's suggestion in comment #28, not sure how to handle specialized instances though. Aside from that, we should keep things simple (not too many buttons, not too many lines in the dialog, ...)
This is still occurring in the latest version (Lightning 2.6.4 on Thunderbird 24.4.0, Windows 7 64-bit). It occurs both when snoozing and dismissing an event.
You need to log in before you can comment on or make changes to this bug.