Double clicking (or inline editing/dragging) on a recuring event in the new views generally only modifies that particular instance. I think there's some magic going on with Ctrl+edit, but it's really unclear to the users. We should probably prompt a question, and maybe even add a banner to the top of the edit dialog.

This patch adds a prompt for whether we should edit the parent item or the single occurrence. In Lightning, all of the mechanics to do this were pretty much there. We just modify the view-controller. In Sunbird, changes needed to be made to other placesas well. -calendarSelection.js needs to stop always using the parent item. Removing these .parentItem calls makes our selection much less broken. -editEventCommand needs to also check for parent items. (There are so many edit/new calls in calendar.js, we need to get those out.)

Comment on attachment 207144 [details] [diff] [review] add prompting >Index: mozilla/calendar/lightning/content/calendar-management.js > deleteOccurrence: function (aOccurrence) { > if (aOccurrence.parentItem != aOccurrence) { >- var event = aOccurrence.parentItem.clone(); >- event.recurrenceInfo.removeOccurrenceAt(aOccurrence.recurrenceId); >- event.calendar.modifyItem(event, aOccurrence, null); >+ var event = getOccurrenceOrParent(aOccurrence); >+ >+ if (!event.isMutable) { >+ event = event.clone(); >+ } >+ if (event.parentItem != event) { >+ var parent = event.parentItem.clone(); >+ // The user chose to just delete this instance of the event >+ parent.recurrenceInfo.removeOccurrenceAt(event.recurrenceId); >+ parent.calendar.modifyItem(parent, event.parentItem, null); >+ } else { >+ event.calendar.deleteItem(event, null); >+ } > } else { > aOccurrence.calendar.deleteItem(aOccurrence, null); > } > } If you move the check to see if the item is actually a recurring item to getOccurrenceOrParent(), you can remove that check from all the callers. Also, it cleans up the code above. You don't need to duplicate the code for deleting the whole item. What does item.parentItem return for the first item in the recurrance set? I'm not sure, and if it is the item itself, then the check won't work. >Index: mozilla/calendar/resources/content/calendar.js > function editNewEvent( calendarEvent, calendar ) > { >- openEventDialog(calendarEvent, >+ openSunbirdEventDialog(calendarEvent, Why do you need to rename the funtion? > calViewController.prototype.deleteOccurrence = function (aOccurrence) { >+alert('single'); >+alert('all'); Remove those dumps, please.

Comment on attachment 207144 [details] [diff] [review] add prompting marking r-, to get this patch out of my queue. Most is OK, just move the recurrance check.

An updated patch for this bug would severely conflict with the new edit-dialog. We need to make a decision asap about whether we're going to press forward with that dialog or drop it until later. (I'd really rather go for it. Even if we end up changing substantial portions of it later, ending this code fork is worth it, in my mind.)

I think we can live without this bug for 0.1. Sunbird 0.2 didn't support editing individual events, after all, and lots of people used that.

Joey pointed out that because the way the UI currently works deals with instances in some cases and events in others (which can probably lead to data-loss by confusing the user) this would be a good thing to have for 0.1. Furthermore, this isn't much work after the new new dialog (bug 296893) lands, which we want because it saves a duplicated work in a bunch of other patches that block 0.1. Adding back to the list.

Soooo much easier now that the dialogs have been merged. The parentItem check works, however, this patch is going to make bug 299651 more apparent, because when 'All Events' is selected, item.parentItem == parentItem and so the prompt isn't offered. Lightning, since it doesn't have a unifinder, doesn't have this problem. re comments from previous review: dump()s have been removed, the function no longer needs to be renamed (because of the dialog switch), the parentItem removal was done in a separate bug, and the parentItem check works, even on the first instance.

Instead of prompting users every time, I'd rather have this selection built into the edit event dialog. It could, for example, have a radio group with the following options: * change this occurrence * change future occurrences * change all occurrences Then the most likely option could be selected by default, and users can change that within the same "editing event" process they use to make their other modifications instead of via a separate popup.

(In reply to comment #8) > Instead of prompting users every time, I'd rather have this selection built > into the edit event dialog. It could, for example, have a radio group with the > following options: > > * change this occurrence > * change future occurrences > * change all occurrences > > Then the most likely option could be selected by default, and users can change > that within the same "editing event" process they use to make their other > modifications instead of via a separate popup. > How would this work for inline editing/dragging of events in the grid?

re Comment #8, we use that method for an internal calendar here, and it seems to work very well, users have no trouble with it, and it's not too intrusive.

> How would this work for inline editing/dragging of events in the grid? For event dragging, the right approach is probably to have the most common behavior be the default but allow users to switch to the other behavior via a modifier key. If that's too hard for novice users to discover, you could add a dialog but include an option to "not ask again" and explain how to obtain the other behavior. I'm not sure how it would work for inline editing, since I haven't used that feature yet and can't find it now that I'm looking for it in today's Sunbird build, but perhaps whatever action the user takes to get into inline editing mode could also be accompanied by a modifier key for switching to the other behavior. For what it's worth, I think there are actually three common use cases for editing recurring events: 1. edit just this instance (f.e. the staff meeting has been moved to Tuesday this week); 2. edit all instances (f.e. i entered it wrong; my programming class actually starts at 7:30pm, not 7pm); 3. edit future instances (from now on, basketball with the guys happens Friday). That last use case is currently poorly supported. At least, I can't find a way to make it happen. I either have to change all instances (corrupting the historical record for what I did when) or create a new event (extra work, plus it breaks the continuity between occurrences of what is really the same event). Enabling the last use case is probably a different bug, but I wanted to mention it here since future plans to support it may impact the way you write the code to fix this bug.

(In reply to comment #11) > > How would this work for inline editing/dragging of events in the grid? > > For event dragging, the right approach is probably to have the most common > behavior be the default but allow users to switch to the other behavior via a > modifier key. I would tend to agree with this. > If that's too hard for novice users to discover, you could add a > dialog but include an option to "not ask again" and explain how to obtain the > other behavior. I would argue that the obvious drag semantic is "move this individual instance", which is what people are going to do far more than the other use cases that Myk cites. If there's another discoverable way (eg dialog) to move multiple instances (eg by dialog), I don't know if we need to worry too much about discovery of the modifier. That said, I'm unclear on how discoverable most users would find a button in the dialog. > I'm not sure how it would work for inline editing, since I haven't used that > feature yet and can't find it now that I'm looking for it in today's Sunbird > build, > but perhaps whatever action the user takes to get into inline editing > mode could also be accompanied by a modifier key for switching to the other > behavior. Myk: click on the title of event, wait very briefly, then click there again. That proposal sounds reasonable to me as well, for the same reason. It would also be interesting to know what sort of UI Outlook and iCal provide for recurrence handling...

> Myk: click on the title of event, wait very briefly, then click there again. I tried that (with a variety of second-click delays), figuring it might work like renaming files in file explorers, but it didn't work for me. But I just tried it with the day and week views (I was in the month view before), and it works there, so I guess it only doesn't work in the month (and multiweek) views.

> I would argue that the obvious drag semantic is "move this individual > instance", which is what people are going to do far more than the other use > cases that Myk cites. For what it's worth, every time I've wanted to drag-and-drog a recurring event, I was always trying to change just the one instance I was dragging and dropping, so dmose's observation is accurate in my case. > If there's another discoverable way (eg dialog) to move > multiple instances (eg by dialog), I don't know if we need to worry too much > about discovery of the modifier. Right, especially if users rarely want to make such changes, and if the dialog has good UI for making them. In general, I think we should avoid confirmation dialogs like the plague, since the app can almost always make an educated guess about what users want to do when they take some action, and making such guesses (as long as their consequences are clearly represented in the UI, and users can undo the wrong ones) makes for a more usable app than regularly asking for confirmation.

Lightning currently doesn't offer any other good way to delete an event other than by using the views. This means that at least for deleting (which can't be done from the dialog), I really think we're going to need a prompt, otherwise we force users to delete every instance of a recurring event. At that point, I think we need to include a prompt for all edits that happen directly in the views. If we take the above as required, I'm not sure whether it's better to offer consistency (the same prompt for all edits, with or without dialog) or do something different in the dialog, which would be one less click/choice in the case that we actually guess the user's intention correctly. Does this make sense to other people? Am I missing something? Opinions?

Some notes how Outlook handles these things: If you double click the event the following dialog appeares: "Title" is recurring appointment. Do you want to open only this occurrence or the series? (*) Open this occurrence. ( ) Open the series. [Ok] [Cancel] If you delete the event the following dialog appeares: Do you want to delete all occurrences of the recurring appointment "Title", or just this one? (*) Delete this occurrence. ( ) Delete the series. [Ok] [Cancel] If you drag'n'drop the event to another day or time no dialog is displayed. The event is just moved but still belongs to the serie. If you want to move all events to another date/time you have to use the edit dialog. --> I like that the dialogs are specific to the task that should be performed. I don't think this should go into the event dialog. --> Instead of having radio buttons + ok button maybe only use buttons? Like: [Modify occurrence] [Modify series] [Cancel] This would need one click less than the radio buttons.

(In reply to comment #16) > Some notes how Outlook handles these things: > > > If you drag'n'drop the event to another day or time no dialog is displayed. The > event is just moved but still belongs to the serie. If you want to move all > events to another date/time you have to use the edit dialog. > I just checked this with Outlook 2003 and I got a dialog also when trying to drag'n'drop a member of a series. However, the dialog just allows for cancelling this operations (if you hit cancel) or for applying it to this single instance (if you hit OK). You have no option to change the whole series by doing drag'n'drop. Apple's iCal does it more consistent: regardless of the operation mode you get a dialog asking you to change all events or only this event or to cancel the operation. But there is a subtle difference: only if you try to modify the *first* event of a series you can change all occurences. For all other events you are asked if you want to change all *future* events. So events in the past are never touched which is quite useful. You do not want to change events in the past. > --> I like that the dialogs are specific to the task that should be performed. > I don't think this should go into the event dialog. I agree. > --> Instead of having radio buttons + ok button maybe only use buttons? > Like: [Modify occurrence] [Modify series] [Cancel] > This would need one click less than the radio buttons. > That's exactly how iCal works. So we would need: [All] [Only this event] [Cancel] for the first of a series and [All future events] [Only this event] [Cancel] for the rest. Those dialogs should appear for all operations: delete, modify, drag'n'drop. There was the proposal in comment #12 that for drag'n'drop the application should assume that per default only the current event has to be changed. I disagree. I always would prefer a consistent behaviour. And, how often do you change occurences of a recurring event ? Not too often I guess, so a confirmation dialog should not be perceived as too annoying.

*** Bug 308557 has been marked as a duplicate of this bug. ***

(In reply to comment #17) > > That's exactly how iCal works. So we would need: > [All] [Only this event] [Cancel] for the first of a series and > [All future events] [Only this event] [Cancel] for the rest. > Those dialogs should appear for all operations: delete, modify, drag'n'drop. In general, the behavior you've described sounds pretty reasonable to me. If we go this route, we might want to put these sets of buttons at the bottom of the "modify" dialog too, instead of making the user go through two dialogs in that case. > There was the proposal in comment #12 that for drag'n'drop the application > should assume that per default only the current event has to be changed. I > disagree. I always would prefer a consistent behaviour. Well, where I was coming from was thinking that this whole "recurrence" thing is, to some extent, an artifact of the data-format of iCalendar. We're showing something that looks quite a bit like a paper desk-calendar to the user, and on paper desk-calendars, all events are singletons, at least as far as how they can be manipulated. > And, how often do you change occurences of a recurring event ? Not too often > I guess, so a confirmation dialog should not be perceived as too annoying. Examples of recurring events that I have on my calendar every day, that I often move around on a per-instance basis include "read email", "read bugmail", "read news/blogs", "reviews". I'd really be interested in hearing any thoughts that beltzner and mconnor might have on this issue.

Current theory is that for 0.1, we'll only allow editing of the parent instance, because there are a fairly sizable number of bugs in exceptions that we don't want to hold 0.1 for.

When you "change all future events" in Apple iCal, what happens to the representation of the event in an iCalendar (.ics) file? For example, say you have a daily event at 9am that started some time ago, and you save the event to ics, it should save as one repeating event with an RRULE. If you now (after several occurrences) change "all future occurrences" to start at 10am, and then you save the event to ics, how does it save? (A. One possibility would be to split the event into multiple repeating events, one for the past 9am occurrences, and one for the future 10am occurrences. If they are in a hierarchical relationship, that might break code that assumes there are only a 2 levels in the hierachy, repeater and occurrences. B. One possibility is to convert all past occurrences into RDATE's by listing each past date with 9am time on date, and leaving the RRULE recurrence to handle the infinite future dates starting with the first 10am date. That preserves the identity of the event, but it seems expensive to explicitly list every past occurrence date in the event.)

"A" makes sense to me, when you alter all future occurrences of a repeating event, it could create a new event duplicate to the original event, then set the end date on the original event to the last occurrence (or similar) and change the start date of the duplicate event to the current event, and then you make whatever change, and save. Of course I have no idea if the code is in place to do that, but that seems a simple enough approach.

(In reply to comment #21) > When you "change all future events" in Apple iCal, what happens to the > representation of the event in an iCalendar (.ics) file? > > If you now (after several occurrences) change "all future occurrences" to start > at 10am, and then you save the event to ics, how does it save? > I don't know how iCal does it, but it seems like the most reasonable option would be to use the RANGE parameter (of RECURRENCE-ID) with a value of THISANDFUTURE. See rfc 2445 Section 4.2.13. Or am I misunderstanding something here?

Comment on attachment 209399 [details] [diff] [review] add prompting v2 r=mvl we can go with this for now, so that at least there is some UI. Other improvements and editing only future events can be done later.

Patch checked in. I'm going to leave this bug open so that we can update the prompt once we have back-end support for editing 'All future occurrences'. Have fun playing around with this for now. We're fairly certain that it's going to be disabled for Lightning 0.1.

Re-assigning to default until we have the story sorted out on where we're going with this. (We need back-end support before further UI can be developed.)

I would like to add some scenario - cancel button/action should be improved: - create new event with repeating every week - drag and drop (using mouse) event, eg move from 12:30 to 15:00 (hour) -> appear confirmation dialog - now I would like to cancel action (do not move event), there is not cancel button so I click x on the top of dialog -> single event was moved, the rest was not touched. Well, I can not cancel so I used "x button" and action has been done, it is not really, what user expect... So simple add cancel button like in some conception above will be nice Stefan's idea with three buttons looks good, comment 16

(In reply to comment #27) Robin is already working on this in Bug 329642.

The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!

Let's figure out what we want the UI to look like before doing a bunch of backend work. My opinion has morphed over time: I've begun to find the dialog box really annoying, because I usually want to tweak a single occurrence and less frequently want to change the entire pattern. It also seems to me that the UI model here is "like a paper calendar", and paper calendars never ask you questions when you're dealing with individual events. As such, I wonder if we don't want an icon or some other UI affordance on the event that has an "edit the pattern" semantic, and the default can always be to edit the individual occurrence. In particular, the "repeat" icon often used by media players and consumer electronics might make a good button for this.

there is easy and very useful option in Firefox: when you close application that has open more than one tab you'll get alert/confirmation if you really want to close all tabs goal is that you can check: don't ask me again and you will not be asked any more you can always get back confirmation in options dialog to improve it: for groups of event you can add new item in context menu: edit groups of event and delete groups of event I never modify single event so current confirmation annoys me :(

Please consider "copying" the mother of all organizers: *Lotus Organizer* +----------------------------+ | Change Repeating Event |X| |----------------------------| | Change | | (o) Just this one | | ( ) All | | ( ) All previous | | ( ) All future | | ( ) All until [dd.mm.yyyy] | | | | [[ OK ]] [ Cancel ] | +----------------------------+ PS. This dialog should be brought up *every* time a recurring event is manipulated (moved, deleted, dragged, etc.).

(In reply to comment #32) > PS. This dialog should be brought up *every* time a recurring event is > manipulated (moved, deleted, dragged, etc.). The benefit, of course, is that recurring events are set up because, well, they are recurring (like monthly staff meetings), and manipulating them together is quite common ("from now on, our staff meetings will be at 12:00 instead of 11:00" --> "All future"). For the cases when the user only wants to manipulate "this" event, all they need to do is hit the <ENTER> key(1), because the default would be "Just this one". (1) The <ENTER> key on the numeric keypad can be reached by simply extending your right thumb (whhile still holding the mouse).

I'd like to point out that we need *at least* "All future" (in addition to the current UI's selections), and adding that as a button to the current UI would overload the button concept. I therefore hope you guys will consider using (the far more flexible) radio buttons dialog (see comment #32).

This bug should block calendar 0.5

We're at the string freeze without a patch. This doesn't block 0.5.

Cc'ing Christian for an UI expert opinion. Maybe there is already a proposal for such a dialog.

Not going to happen for 0.8.

Not going to happen for 0.9.

This feels like it probably blocks tb-integration to me, though it's conceivable I could be talked out of that. Plussing.

I'd recommend a dialog that appears after editing; either dragging or through the event editor. This way we can keep a consistent dialog and timing for our interaction. I believe the relevant and common options are going to be these three: * change this occurrence * change future occurrences * change all occurrences Changing 'previous occurrences' is an obtuse concept that can still be accomplished if a person changes all occurrences and then updates all future occurrences. And I'd leave out the option for changing All until [ DD / MM / YYYY ] as it seems useful except that it is too structured and so introduces some empty concepts a person would have to deal with. To make it a single click operation I wouldn't use radio buttons, but regular buttons with most of the action text in the button itself. +------------------------------------------------------------------------------+ | Editing Reoccurring Event | | $TITLE | | /Were you editing just this event, all events in this series, or all | | events in this series from now on?/ | | | | ( Only this event ) ( All occurrences ) ( All following occurrences ) ( Cancel )| +-------------------------------------------------------------------------------+ Only this event - changes the single event and leaves the series as is All occurrences - changes all events in the series All following occurrences - changes this and all future events in the series Cancel - undoes the edit, for drag and drop the element returns to it's original position. With the edit window we make it reappear with the changes the person was working on loaded. They will have to cancel again to lose their changes.

I believe that the "all occurrences" button is (most of the time) not worth the real estate / mental decision space it consumes. iCal's behavior as documented by comment 17 seems like a pretty good target to me.

Yes, just talking to dmose over irc and he reminded me how the 'All occurrences' doesn't have much of a use case behind it. You're only really ever interested in the future events as they can have a real effect on you. Buttons when editing the first event in a series +---------------------------------------------------------+ | | | ( All ) ( Only this event ) ( Cancel ) | +---------------------------------------------------------+ When editing any event but the first or last in a series +---------------------------------------------------------+ | | | ( All following events ) ( Only this event ) ( Cancel ) | +---------------------------------------------------------+ Of course it might be nice to offer a subtle way to open the original event from any of the subsequent events. This would be informative of when the first event was and wouldn't impede the common path we're aiming to fix. This could possibly be somewhere in the event editor as a link displayed as "first event in series". Just an idea

I suggest to take a look at a 0.9pre nightly build. The occurrence prompt was completely reworked recently in Bug 363932 and already offers a one click action.

(In reply to comment #48) Let's please keep the button texts as short as possible (while still making sense, of course), make "Just this one" the default, and not provide multiple versions of the dialog: +---------------------------------------------------------+ | Change Repeating Event |X| |---------------------------------------------------------| | Change: | | | | ( All following ) (( Just this one )) ( Cancel ) | +---------------------------------------------------------+ Somehow "Just" seems more appropriate (terse-sounding) to the intent of this button than "Only". I don't think we should change the button text merely on the basis of whether the edited event is the first, last, or within the series. It provides inconsistency and confusion, and I don't see what benefit it provides. Re. "All following": I wonder if users will more often want to change "all following" *including the currently selected one* (i.e., this one and all following ones)? :-\ That's much harder to formulate concisely though. PS. I still prefer the radio buttons method. It's plenty efficient, can provide more options, is easier to visually scan, and provides the user that extra second before making a potentially damning one-click mistake.

(In reply to comment #46) > I'd recommend a dialog that appears after editing; either dragging or through > the event editor. This way we can keep a consistent dialog and timing for our > interaction. I think this would be confusing. I, and I suspect most users, would feel uncomfortable about editing an event before knowing that it is clear which event(s) I am editing (or potentially ruining).

(In reply to comment #50) > > Somehow "Just" seems more appropriate (terse-sounding) to the intent of this > button than "Only". I have to admit, I kinda like this, despite it seeming less formal. > Re. "All following": I wonder if users will more often want to change "all > following" *including the currently selected one* (i.e., this one and all > following ones)? :-\ That's much harder to formulate concisely though. This sounds like it more correctly describes the common use case to me also. "This and future" is one way to frame it. > PS. I still prefer the radio buttons method. It's plenty efficient, can provide > more options, is easier to visually scan, and provides the user that extra > second before making a potentially damning one-click mistake. As long as "Undo" works, it seems like a better way over coping with mistakes than slowing down the user on every action.

(In reply to comment #52) > > This sounds like it more correctly describes the common use case to me also. > "This and future" is one way to frame it. > How about "From now on" ?

(In reply to comment #51) > I think this would be confusing. I, and I suspect most users, would feel > uncomfortable about editing an event before knowing that it is clear which > event(s) I am editing (or potentially ruining). I'm not sure I understand you here. A person can edit the event they selected for editing, then upon clicking save (keeping the dialog in view) we can prompt if they want to just change that event or all events. After the save a person can review all the changes they've made to the event and decide if it applies to more than just this event. Prompting about which event in the series before the edit happened requires the person to summarize the changes they are going to make in their head and determine if those changes apply to more than just this event. It's a little more difficult mental process than just reviewing the changes made and deciding. I can't see why prompting before would be better.

(In reply to comment #54) > (In reply to comment #51) > > I think this would be confusing. I, and I suspect most users, would feel > > uncomfortable about editing an event before knowing that it is clear which > > event(s) I am editing (or potentially ruining). > > I'm not sure I understand you here. A person can edit the event they selected > for editing, then upon clicking save (keeping the dialog in view) we can prompt > if they want to just change that event or all events. After the save a person > can review all the changes they've made to the event and decide if it applies > to more than just this event. > > Prompting about which event in the series before the edit happened requires the > person to summarize the changes they are going to make in their head and > determine if those changes apply to more than just this event. It's a little > more difficult mental process than just reviewing the changes made and > deciding. I can't see why prompting before would be better. > Except I'm pretty sure people already know before they sit down whether the event is changed for all future, or just once. This is part of the set of information they have when they sit down to change it. They know if it's cancelled, or rescheduled, when to, and how many times. I know I would be put off/confused if I had information that I couldn't seem to add in the dialog. I wouldn't expect to be prompted for specific pieces of information afterwards.

(In reply to comment #55) > Except I'm pretty sure people already know before they sit down whether the > event is changed for all future, or just once. This is part of the set of > information they have when they sit down to change it. They know if it's > cancelled, or rescheduled, when to, and how many times. I know I would be put > off/confused if I had information that I couldn't seem to add in the dialog. I > wouldn't expect to be prompted for specific pieces of information afterwards. Actually I'm not assuming that everyone thinks of any event sitting on their calendar as a single event in a series or a single event not in a series. When choosing a single event which happens to be in a series I don't think everyone is thinking of all weekly meeting events as much as the one they clicked on. Also consider that the undo interaction steps get bad. If at first you choose only this instance and then after editing you realize it really should be all instances... How do you go back to make that choice? You would have to cancel out all the changes you made and start over, selecting all events this time. Additional designs could be made to accommodate this change by adding in [All of Just This] as a radio button either instead of or with the dialog. But that series of design decisions is simply to support having the dialog up first. And all or single is an important distinction that I wouldn't want to have it missed in a radio button choice.

The real damage is only caused if you chose all but only one event changed. If you only change one but meant to choose all you click on the next one and change them all again. So I think I understand what you're saying but I still don't get why. Boss says "from now own, our team meeting is at 3pm instead of 2:30pm" You sit down with the knowledge that you need to now change *every* instance of that meeting in the future. I don't see how someone would sit down and think "Ok let's change the one for this week."

1) If you remove the "All Occurrences" option from the popup (when you click on an occurrence that is not the first), please put it in the context menu or somewhere. Consider the case of a recurring birthday event for someone who was born in 1920. I wouldn't want to navigate the view 88 years into the past to change or delete the whole series. 2) "From Now On" is a good idea, but I think it would be too confusing when someone wants to change an occurrence in the past or future because the time of the occurrence isn't "Now". Thus I prefer "This & future" (or similar).

Granted the bug title is about adding UI for this action, but since we need an implementation to split up the event to the ones before and after for the "this and future" choice, we either need to file a separate bug for that, or use this one for it. The suggestion about moving the choice to the end of editing might be a good idea (although I'm quite used to it and like the way it is now), but that definitely needs to be done in a different bug. It is a major step and needs lots of changes in the event dialog, and the above mentioned split itself is a *massive* piece of code (I know, it sounds trivial, thats what I thought at the beginning too!) I'd also prefer "This and following", I thought about similar suggestions you guys came up with and came to the conclusion that this and following is the best description for it. I agree to Majken's use case in comment 57, which makes me think we might actually be on the right path the way things were. I personally think that iCal's way of making assumptions about what the user wants to edit might be great for new users, but power users feel they have too little control about whats happening with their events.

I'd like to ask reconsideration for tb-integration+. The code for this bug is far from trivial, alone the function to split a recurring item into two separate events is almost 200 lines long and still has problems that will bloat the function even more. Personally, I think this is something a email client with calendaring capabilities initially can live without. While Dan argumented (over irc) that this is a fundamental calendaring capability, given the fact that this bug hasn't had too much non-developer traction and also no votes I think its something users can live without.

What sort of non-developer traction do calendar bugs get? This bug has also been fairly active, might explain the lack of votes. Though this one is easy enough to work around by creating new events, so that might explain the lack of users commenting/voting. Keep in mind TB users are going to be a completely different game from Calendar users, just like Firefox Beta testers are different from release users.

tb-integration- I don't we'd block integrating lightning over this.

I've been a Sunbird user for a while now, and I would agree that it's frustrating to create a new event instead of being able to modify future events independently from the past. Even if creating a new event, there is no easy way to delete all the future events while leaving the past events intact. They must be deleted one at a time. My suggestion would be something similar to what I've seen in Lotus Notes: Just this instance All instances This instance and all previous instances This instance and all future instances

As a former user of Lotus Organizer throughout its lifetime, I would strongly favor the proposal made in comment 63. It's simple, to-the-point and says what it needs to say. Yes, this is not exactly the bug I searched for (I doubt it can be found) it is closely related and may have prevented my bug from ever surfacing or existing. As a former developer and current user I've found this discussion very interesting but can't understand why it has been going on for more than two years. I like Thunderbird and the addition of Lightning has helped make it complete for my purposes. Lately, they have not been cohabitating very well. But that's a slightly different problem. I haven't found the front door to bug reporting yet.

(In reply to comment #66) > I haven't found the front door to bug reporting yet. Here's the "front door": https://bugzilla.mozilla.org/ https://bugzilla.mozilla.org/enter_bug.cgi

Could someone please add "repeating" to the subject to make it more findable?

Hi, using sunbird 0.9, ok but I keep needing this functionality: edit/delete gives choice for "this event" or "all events" but "all future events" is very often the actual thing I need to do. Vote up comment 63 pls

Lightning is missing a "Future events only" option for editing recurring items. This is important for events such as a client rescheduling a weekly appointment. I will be stuck with KDE-PIM until this common use case is addressed. Thank you.

Hi I support strongly all those who have requested the possibility to edit/delete - a single event - all events - future events only (leaving past events untouched). The last has become so essential that I am regretfully going to have to give up SunBird (used for several years, currently v. 0.9) in favour of another calendar organizer.

So in Lightning 1.0b2, there's now a dialog that asks if you want to "Edit just this occurrence" or "Edit all occurrences". The problem is that for invitations the user has accepted, the resulting window (either choice), doesn't let you edit anything!

This is still very much needed. With the new dialog to choose whether to "Edit just this occurrence" or "Edit all occurrences", how big will the effort be to add another option "Edit this and all future occurrences"? Comment #21 includes two suggestions how this could be achieved. Effectively, I would even be satisfied if I could only delete "this and all future occurrences", and add a new event manually. For events where I am the organizer, I could of course just change the End Date. However, there are events where I am not the organizer that I would like to delete but keep the past occurrences in my calendar.

As Jonathan said, this is still very much needed. Options needed: "Edit this and all future occurrences" and "Delete this and all future occurrences".

For a few releases I had this capability and now it is gone. It is really critical if TB-Lightning combination is to remain any kind of challenge to Outlook. The suggestions for a possible UI to take care of this bug back in 2006 through 2008 are still valid in 2015. Again beginning to be an epic fail for me to continue to support TB in the corporate arena.

Editing all future events of a recurring series has never worked in Lightning nor Sunbird. If you have trouble editing/deleting single events in Lightning, please file a new bug.

(In reply to Philipp Kewisch [:Fallen] from comment #83) > Editing all future events of a recurring series has never worked in > Lightning nor Sunbird. If you have trouble editing/deleting single events in > Lightning, please file a new bug. it must have been an add on. Our office had the capability and several people I know outside of our office did as well. Previously, editing a recurring event also did change previous events. Now it does. I had 4 choices in the pull down box instead of 2. Perhaps this capability occurred through the old google provider api and the use of google calendars which we no longer use. regardless, contrary to your comment, we did have the capability and it is one that is sorely needed at this time. Respectfully,

Hello everybody, I'm a bit suprised of this nearly six years old thread. I always wondered if there is a possibility to edit a series of events started from a selected date. Every other popular calendar software does in deed offer this. I think it's no problem to upgrade the calendar in thunderbird with the new functions "Delete this and all future events" and "Edit this and all future events". So basically we need an alternate option list while trying to delete or edit a not-first event of a periodic event: * edit/delete all events * edit/delete this event * edit/delete this and future events The last option should change the ending timestamp of the existing event and to the actually clicked time/date and (in case of creating a new event) open the "add new event" with the same properties like the already existing event whilst changing the starting time to the clicked time/date. Pretty easy I think...? Kind regards!

It would be nice if at least the feature "Delete all future events" could be implemented. If I want to delete an repeating event I get asked about "Delete one/Delete all". It would be nice, if there would be the third option "Delete all future events". That just means: set the end date of the repeating event to the marked date. It is no big change in data. Thanks

But what about "Delete all past events" ? And delete it at all - without move it to exclusion-list.

(In reply to Nick from comment #87) > But what about "Delete all past events" ? I never needed to delete old events. I just keep them. > And delete it at all - without move it to exclusion-list. What is the exclusion-list?

When I export calendar as ICS-file for import it in another software - I can see this: EXDATE:20170512T050000Z EXDATE:20170513T050000Z EXDATE:20170514T050000Z EXDATE:20170515T050000Z EXDATE:20170516T050000Z EXDATE:20170517T050000Z EXDATE:20170518T050000Z EXDATE:20170519T050000Z EXDATE:20170520T050000Z EXDATE:20170521T050000Z EXDATE:20170522T050000Z EXDATE:20170523T050000Z In professional CRM-soft I can mark event as "did" and it became strikeout and it`s copy appear in history...

Apologies to all the rest of us getting spammed by this bug today. Please, people... Read the subject of this ticket. It deals specifically with a UI feature to edit/delete single or all future occurrences of a recurring event. It has nothing to do with deleting past events, using add-on applications, nor is this a discussion forum and this ticket a thread. This is a task-tracking feature request specific to dealing with repeating events which have not occurred. Please review https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before compounding the problems of bugspam for all of us. Please do not post follow-ups to this post, as I am not looking to engage in discussion. If someone has a patch to submit to enable this UI feature, please do so, by all means, and the code may be reviewed on its merits. Thanks