Open Bug 1668719 Opened 2 years ago Updated 8 months ago

After updating to TB 78, cannot change individual occurrences of a pre-existing recurring event series

Categories

(Calendar :: General, defect)

Thunderbird 78
defect

Tracking

(Not tracked)

People

(Reporter: davelabrecque, Unassigned)

References

Details

(Keywords: regression, Whiteboard: DUPEME)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36

Steps to reproduce:

Tried to change the title of a single instance of a recurring event.

Actual results:

I open the event, get a prompt titled "Edit Repeating Event" that gives me two choices: "Edit only this occurrence" and "Edit all occurrences." I choose the former and click on it. The event edit dialog opens. I change the contents of the Title field and click "Save and Close." I get a prompt with the event series details shown (including the origination date of the series) and the message: "This item has recently been changed on the server. Submitting your changes will overwrite the changes made on the server." I don't know why I get this prompt, but there are two choices: "Submit my changes anyway" and "Discard my changes and reload." I click on the former. The prompt clears and then returns after a brief pause. I click on the button again and get the same response. And again. Ad infinitum. The only way to clear the prompt is to click the latter choice, and so my individual event title edit attempt has failed.

Expected results:

First, perhaps the prompt should not appear at all. Second, when I tell it to submit my changes, it should do as it's told and submit my changes.

I used to be able to do this before I updated to TB 78. Also note that the recurring event series predates my updating to TB 78. Although I've had a similar experience with newly created event series (in this current version, TB 78.3.1 x64) as well.

Component: Untriaged → General
Product: Thunderbird → Calendar
Whiteboard: DUPEME
Version: 78 → unspecified

Dave, does this happen while using a CalDAV calendar? This is probably a duplicate of bug 1668386 .

Flags: needinfo?(davelabrecque)

Yes. This is both using CalDAV "straight-up" as well as using the TbSync/Provider for CalDAV & CardDAV combination. I does appear to be a duplicate of bug 1668386. The only new info appears to be that this bug creeped in with version 78.x, so sooner than 82 (as outlined in bug 1668386).

There are three other issues I've noticed, which, I'm guessing, are related to this bug:

  1. Can't delete an individual occurrence of a series created in pre-78 TB. The same insistent "server" prompt appears (and shouldn't, I think).

  2. When a recurring event appears in the floating Reminders window, dismissing it is not possible. Clicking "Dismiss" brings up the same "This item has recently been changed on the server..." prompt (I don't think it should), which again can only be cleared by discarding changes.

  3. When I try to copy a single occurrence of a recurring event (right-click event, select "Copy only this occurrence") and then paste it, I get an event that appears to be set as an recurring event when examining it's Edit Event window: double-click on the pasted event to open it, get a choice of editing this occurrence or all occurrences (there should be no such choice), choose the latter to investigate, the Repeat drop-down says "Custom...", clicking "click here for details" shows Repeat set to "daily" with no end date (the original from which this series was copied had a weekly recurrence set to "Forever"), yet the Preview section at the bottom shows no dates highlighted. Note that while this pasted event appears to be erroneously set to recur as I've described, checking other dates on the actual calendar reveals that this new "series" does not actually show any other dates on which it recurs, daily or weekly.

Flags: needinfo?(davelabrecque)
Summary: After updating to TB 78, cannot not change individual occurrences of a recurring event series → After updating to TB 78, cannot change individual occurrences of a recurring event series
Summary: After updating to TB 78, cannot change individual occurrences of a recurring event series → After updating to TB 78, cannot change individual occurrences of a pre-existing recurring event series

More info. This bug does not appear to be limited to single instances of recurring events. Even trying to change the entire series fails:

  1. open recurring event created pre-version-78.x
  2. choose "Edit all occurrences"
  3. click Until drop-down, currently set to "Forever"
  4. choose end date, click Save and Close
  5. get prompt to submit or discard changes (only dismissable by discarding changes)
Duplicate of this bug: 1665982
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Thunderbird 78

I think bug 1664731 fixed this. Can you try today's nightly?

See Also: → 1664731

Sorry, no time till after Christmas to try a nightly. But I can tell you that I just updated to 78.6.0, and the bug persists in that version. Don't want to risk a nightly update with no time to restore, etc., if something goes bad.

Uh-oh. Looks like the bug is even worse, now. I believe it used to apply (in the early-78 releases) only to recurrent event series that had been created prior to updating to TB 78 (and migrated over into 78). Now I'm getting the same problems with NEW recurring events I'm creating. Can't change or delete an individual occurrence. :(

Well, yesterday I couldn't delete or change a single occurrence of a newly-created series. Today I can delete such an occurrence; I just can't change it (and I get the server prompt that won't go away till I cancel it).

It seems I encounter the same bug since I tried to update to the latest version 78.7.0.

To fix the issue, I've tried to revert to older versions, such as 78.6.0 and 78.6.1 (downloaded from public directory listing) and using a backup copy of the profil, but it seems surprisingly not to work: all recurring tasks previously set continue to be displayed as initially drafted and not with any punctual modifications (e.g. titles, dates, etc.).

It seems this kind of changes aren't properly saved now and, above all, not kept when Thunderbird is relaunched...

I continued some testing on this issue today, and it seems that concerning tasks, the problem persists even with new calendar and recurring task, both created from scratch using the latest version of Thunderbird.

In addition, some modified tasks (for example noted as completed) retain their changes, while others are completely reset when the application is relaunched. From my testing, it appears that the normal behavior occurs more often with the very first occurrence of a recurring task.

This issue is very problematic when you have many recurring events or tasks that are very regular (especially daily or weekly).

For example, in one of my calendars, a recurring weekly task had been active since 2015: while all previous occurrences were marked as completed since a long time, I saw more than 260 (supposedly) overdue tasks reappear!

Thanks for your efforts. Yes, this is a huge bug that is, apparently, getting very little attention. It creates all kinds of problems for me in my event scheduling and updating that I never used to have to worry about. And it's been this way, now, for months. :(

(In reply to Dave Labrecque from comment #11)

Yes, this is a huge bug that is, apparently, getting very little attention.

I'm afraid to assume that there are probably few users who experience this problem. This may be due to our specific configurations.

It creates all kinds of problems for me in my event scheduling and updating that I never used to have to worry about.

Indeed, I had never encountered such a huge issue with Calendar in years. During a previous update to version 78.4.2, I encountered a first (minor) issue that I immediately reported (and which seems to be being processed).

However, this new regression is much more troublesome, but surprisingly it only appeared on my own installation when updating to version 78.7.0 and not before. However, I'm assuming that the problem existed previously, firstly because of your own initial bug report, but also because by testing my backup with several previous versions, the problem turns out to be persistent.

However, after continuing my series of tests, I finally managed to (temporarily) solve the problem: by reinstalling my previous backup with an old version 78.5.1, the functioning of recurring tasks and events seems normal again (at the moment). I guess this might help specify the version from which the regression in question seems to have arisen.

Finally, by rereading the various previous comments above, I realized that the issue I faced on was however slightly different: indeed, it does not affect calendars in CalDAV format (as you mentioned in comment #2), but more simply local calendars. At this time, I don't think it's useful to overload maintainers by opening another specific bug report separate from your own until this one is fully reviewed.

I finally managed to (temporarily) solve the problem: by reinstalling my previous backup with an old version 78.5.1, the functioning of recurring tasks and events seems normal again (at the moment).

I had done well to say temporarily and at the moment, because after less than 24 hours (while everything was back to normal), suddenly all reccuring tasks or events which have been manually modified become again "overdue" (using local calendars with version 7.5.1). What a headache! 🤯

Oh, that's too bad. I was about to install 78.5.1 to get things working, again.

This is really bad for me. I have a need to update individual events in recurring series all the time, like every day. And it just won't cooperate.

Yesterday one of my calendars even stopped syncing with my Google calendar, and bunch of events have just disappeared from Thunderbird. :(

I can't imagine this isn't impacting a lot of people. In this case open-source does not seem to be working very well.

(In reply to Dave Labrecque from comment #14)

Oh, that's too bad. I was about to install 78.5.1 to get things working, again.

So, I was so obsessed with these event and task issues, that by reinstalling version 78.5.1, I forgot to turn off the automatic update. 😣

Therefore, I resumed my old backup, reinstalled the emails downloaded in the meantime, deactivated the automatic update... And it seems that it works (for now).

This is really bad for me. I have a need to update individual events in recurring series all the time, like every day. (...)

Until then, I also worked a lot with recurring items, but given this current issue, I'm doing a huge cleanup of my calendars (by transforming various current items without using any native recurrence, as this feature seems currently broken for me).

I can't imagine this isn't impacting a lot of people.

This is one of my true questions right now ... What makes this major problem seem to impact only a few people? Are so few of us using recurrences? I have read (a little late) only one comment on this issue (in addition to your own bug report).

In this case open-source does not seem to be working very well.

Note that everything has worked very well for years: it's difficult to definitively criticize about just this kind of regression (even if it gets troublesome impact on our own way to use this software).

Yeah, I guess if it's not impacting a lot of people (which seems to be the case?), then my open-source comment is inappropriate.

I, too, have done some experimenting. I went back to 78.5.1 for the heck of it. I created a new recurring event and was able to delete or edit individual instances. But I could do that sporadically with the most-current update, too, so nothing earth-shattering, there. Nothing conclusive.

I was hopeful that regressing the version would also fix this other issue I alluded to: one of my calendars no longer syncing properly with it's associated Google calendar. Alas... the problem persisted post-regression.

Then I did some Googling about how to make the Thunderbird/Google sync work (I always forget the details), and came across a post saying I don't even need add-ons to do this. I've had both "TbSync" and Provider for "CalDAV & CardDAV" enabled as extensions! For whatever reason, I'd had to install both (I thought) to get the calendar sync to work.

I disabled the problem calendar in Thunderbird. Then I disabled both of those extensions and simply added a new calendar as a CalDAV calendar, syncing it to the Google calendar that had stopped syncing. This functionality is all right there in Thunderbird! And it worked!

So my current theory is that running those two extensions together were conflicting, somehow. And now I have a hypothesis: now that I have those two extensions disabled, my recurring series issues will not recur. Fingers and toes crossed.

This would explain why loads of folks aren't experiencing this "bug." It may also explain why the problem seemed especially bad with recurring events created before moving to TB 78. THAT'S when I added those two extensions. Just a thought.

But you, P.Mergey, are a test case, also. Do you have any such extensions running that you could try disabling to see if the "bug" goes away?

BTW, non-extension CalDAV sync instructions can be found in the second half of this post: https://support.mozilla.org/en-US/questions/1304356#answer-1368791

Here's the latest: with NO SYNC EXTENSIONS enabled, I have five or six Thunderbird calendars syncing bi-directionally with Google calendars in TB 78.7.0 x64. I've also got CardBook running successfully for bi-directional sync of my google contacts in Thunderbird. Though this method appears to add a whole new contacts interface in addition to TB's native one, which is a little less streamlined than I'd like. But it seems to work.

Fingers and toes crossed...

Do you have any such extensions running that you could try disabling to see if the "bug" goes away?

I'm testing again the new version (78.7.0) of Thunderbird, because recurring elements (tasks or events) seem to also go wrong with the older version (78.5.1) that I had reused.

I only have two extensions currently installed on my profile:

  1. Remove Duplicate Messages
  2. Signature Switch

By disabling these extensions, there is no change: the recurring elements continue to be defective in a completely random way, in particular modifications of a single occurrence (change of date, category, title, etc.).

For example, I have just tested a recurring daily event set on a single week : modifications made on two occurrences (one with status and another with category) are properly kept when an third (with title modified) is reset each time the app is relaunched.

However, this issue doesn't seem exactly similar to yours though, as I only use local calendars. However, I hesitate to open a new bug report, because by looking a little more, I have seen that some others already open might be related (cf. bug 1688449 or bug 1688708).

If you provide a series of steps to reproduce, I'm happy to test it on my end. Or is it too random for that?

Dang. I really thought I had this put to bed. All seemed to be acting correctly. But today I went to update a single occurrence of a recurring event series, and it failed, but in a different way. I opened an recurring event for this coming Monday, selected "Edit only this occurrence," then saved it. It looked fine in the calendar, but when I clicked the synchronize button to write it to the cloud, the cloud appeared to override it; it returned to how it was before the edit. :(

Oops. Skipped a step. Opened this occurrence of the event, edited it (changed some text), then saved it.

However, I WAS able to delete the current single event from there series (and replace it with one that showed the edits I was trying to make) and have that sync to the cloud. So there's a work-around that wasn't possible before (i.e. since I disabled all my calendar sync extensions).

Just a heads up: This bug persists as of TB 78.7.1. Tried upgrading, hoping it was resolved with the DAV "improvements" but alas, no go.

So far, reverting to 78.6.0 continues to be the ONLY way to fix this...with the caveat of having to go back and (re)mark all past tasks as being (re) completed up to today's date.

But doing so does hold through synchronizations. Any version beyond 78.6.0 just brings 'em all back from the server as overdue/not completed.

Can't duplicate that, here, I'm afraid. Went back to 78.6.0, created a new recurring (weekly) event. That worked.

Then tried to delete a single occurrence. That worked.

Then tried to edit one occurrence of the series by adding some text to the title. Upon saving, I get the server prompt that won't go away till I click "Discard my changes and reload."

So, same as the original bug report, but with the improvement that now we can, at least, delete individual events of a recurring series.

That's strange. Because I routinely use tasks for keeping track of upcoming bills. So, for example, I have a recurring (monthly) electric bill with an average amount due in the title field. When the actual bill comes in, I routinely change the title to the actual amount and actual date by modifying that single upcoming occurrence.

Just to test and duplicate your efforts, I (On 78.6.0, Linux version of Thunderbird, syncing against my Nextcloud server on my LAN):

Created a brand new recurring weekly event. That worked.

Deleted an upcoming single occurrence. That also worked.

Edited another occurrence by changing the title. That also worked.

Did a full sync against the server to make sure the tasks didn't "come back from the dead." They didn't.

But with any version past 78.6.0? Recurring tasks reappear that I've deleted/modified/marked as complete. And I constantly get that "Changed on the server...resubmit my changes or discard" prompt. As I previously noted, reverting back to 78.6.0 fixes everything for past recurring tasks returning which I then have to go through and remark as complete again. And since I have about 5 recurring daily tasks going back to January 1st of this year, that takes some time to do every time they issue an update and I decide to test if this bug has been resolved! And it gets worse the later in the year we get!

I've noticed that sometimes individual events of a recurring series CAN be updated, but usually, they can't. Today I tried creating a whole bunch of different kinds of recurring events, looking for patterns. The best I can say is that it usually doesn't work, but occasionally it does (i.e. the ability to change a single event in a recurring series). And when it DOES work, it consistently works for that individual event (it can be edited/changed many times, successfully). But the others in that same series consistently DON'T allow changes (and trigger the ineffectual server-overwrite prompt).

Also, there seem to be a few recurrent frequency settings that work consistently across the board. Like "Every third day." That one always allows individual event changes within a recurring series. No idea why.

Not much of a pattern. But that's all I got. Maybe someone with more knowledge will see a clue here?

I'm on TB 78.7.1 x64, btw.

Just now seeing your last post, ac064cb8. Looks like we're getting different behaviors. Maybe due to our different cloud-syncing approaches? As I mentioned, I'm not using any extensions, just the native CalDAV functionality of TB to sync my TB calendars with my google calendars.

BTW, I do the exact same thing with a couple of my bills. I have a recurring monthly event with a blank for the new balance amount due; I used to be able to just fill that amount in each month, updating the individual event, but it no longer works. Not consistently, anyway. :(

My work-around is to either delete that individual event in the series and create a single replacement event OR (new thing I'm gonna try) do the single-event-of-the-series update in the Google calendar (browser) interface and let that trickle down from the cloud to my TB calendar.

(In reply to Dave Labrecque from comment #28)

Just now seeing your last post, ac064cb8. Looks like we're getting different behaviors. Maybe due to our different cloud-syncing approaches? As I mentioned, I'm not using any extensions, just the native CalDAV functionality of TB to sync my TB calendars with my google calendars.

That's indeed possible, though I'm not using any extensions related to that either (IE Just the native CalDAV of TB to sync my TB calendars to NextCloud).

I can try and sync to a Google calendar to see if I can duplicate your observations. Question: How did you add your Google calendar: By Locate your calendar as format "CalDAV" with a Username and Location on Google or by specifying "Google Calendar" and picking an existing session or email address? I'm assuming the former since the latter doesn't seem to support tasks at all from what I can see.

Just realized: I think you are referring to recurring calendar EVENTS rather than recurring calendar TASKS. I added my Google calendar to TB (by specifying the calendar method above after realizing that it does indeed support tasks) and found that it does not allow RECURRING TASKS at all! Only recurring EVENTS.

To be honest, all this sync stuff is kinda over my head, but I think the former of your two options is the one I used. When setting up new calendars in TB, I chose "on the network" and put in the appropriate unique CadDAV location address for the google calendar I wanted to sync to. My gmail address was in there, somewhere, too, I think. Or maybe that's part of the address. I don't remember.

Yes, I'm referring to calendar events. I don't use tasks. Haven't found them to be helpful (maybe I just never figured out how to use them). Sorry, I therefore know nothing about trying to sync tasks.

I'm really just writing to say "Me, too", since I see that not many people have reported this problem.

My experience is slightly different from davelabreque's. I have several recurring events, mostly monthly. I created custom categories. Each month, I edit the single occurrence of the event for that month and change its category. I use a local calendar only. No add-ons.

These category changes are getting lost. It really makes the calendar almost useless for my purposes. I've been using it this way for about four years.

The problem started after an update a few months ago. I honestly don't remember exactly when. I generally just update when I get a message that there's one available without reviewing changes, etc. I'm on release 78.7.0 (64-bit) for Windows. (I see there's another update available now.)

Oh, and I have the problem where events don't show at all in the list until I click the hide/show icon next to the specific calendar. I had to search quite a bit to even find out about that hide/show trick, since this never used to happen.

I also have the problem, which existed in older releases, where an event disappears from the list after I edit it. I have the list set to show events for the next 31 days. When I edit a specific instance of an event, save and close, it disappears from the list. If I change the list to show the next 7 days, and then back to showing the next 31, it the edited event will once again be in the list. This is a nuisance.

I'm hoping these are all related and will all magically be fixed in a new release.

Well, here's my latest update.

I've disabled the calendar sync-type extensions, relying on Thunderbird's built-in (native) CardDAV capabilities to sync several of my calendars with corresponding Google calendars. Seems to be working fine EXCEPT that (new behavior) NOW when I edit a single event in a recurring series of events, it works fine UNTIL the next synchronization, wherein the server data undoes the edit and returns the event to it's original state (same as the other events in the series).

Gonna try the work-around of doing my individual event edits directly in my browser on the appropriate Google calendar.

UPDATE: well this is screwy. I went to my Google calendar only to discover that my edit correctly manifested for that single event in the cloud, while my Thunderbird local calendar event was reset as described. What's up with that?

The plot thickens...

The above behavior is consistent across the following calendar views: Day, Week, Month.

However, when I go to Multiweek view, the correct (edited) content displays for that edited event! But then if I close/reopen TB, even the Multiweek view fails to show the correct edited-event info. Argh...

Nevermind, I guess.

I guess this is a different bug than the one I reported up top? Maybe I'll open a new one.

Oops. I said CardDAV, above. I meant CalDAV.

Okay, opened a new bug.

The latest is that even when I change the individual occurrence on the Google Calendar side, while it does initially populate correctly in TB via synchronization, it soon reverts to it's unedited form there.

My new work-around is to simply delete the individual occurrence (which I am able to do without issue) and replace it with a single, new event that reflects the edit I want to make. A bit of a PITA, but it works.

My experience with matches what Dave reported long ago. That is, when I "Edit only this occurrence" of a recurring event (with Google Calendar configured with CalDAV), I get a message showing "This item has recently been changed on the server. Submitting your changes will overwrite the changes made on the server." And every time I click "Submit my changes anyway," the same error just comes back again.

I am using Thunderbird 78.10.1 (32-bit) on Windows 10. (Off-topic rant: This is a newer version than the ones mentioned above even though 78.10 is a smaller number than 78.7 or 78.8. The numbering is very confusing for some of us; should start with 79.01 next time!)

This bug persists with 78.12.0 (64-bit). How would we check the progress or get a feel for how long it might be till it's fixed? It's really an obnoxious problem for anyone who's trying to work with and edit individual instances of recurring events. Maybe this is simply the price of open-source? :^(

Okay, so this seems important:

I had been running my TB calendar/Google calendar syncing by virtue of no extensions and manually entering my Google-Calendar-provided location URL info into TB for each sync'd calendar's setup. A couple days ago I came to realize that Provider for Google Calendar was still useful after all (I'd thought extensions were no longer needed and so didn't use any); I learned how much time and effort it saves by automating the setup process, which is really handy when setting up or re-setting up several sync'd calendars in TB.

And now that I've been using Provider, this bug no longer manifests. I'm guessing it's because Provider is using a different location string than I'd been entering manually. But I really don't know.

Anyway, it appears that this "bug" is limited to anyone doing it the way I used to do it. Which is probably not the "right" way to do it, anyway.

I HAD BEEN following instructions I'd found for manually copy/pasting the Google-Calendar-provided URL string from my Google account calendar settings to TB (actually, I think I had to edit the string somehow or only copy a portion of it IIRC), and it seemed to work otherwise, so maybe this is still worth chasing down. Or maybe not. I leave it in (more knowledgeable) others' capable hands.

And if it's boiled down to a waste of time for anyone, I apologize. I sure THOUGHT I was doing it in a way that had been deemed appropriate. After all, I saw it on the Internet...

Update: while using the straight-up CardDAV approach I allude to above does suffer this bug, using Provider for Google Calendar instead has it's own issue. See Bug 1731301. The Provider developer says it's supposed to work that way. Which is different from TB's native behavior. So I can't follow his thinking.

You need to log in before you can comment on or make changes to this bug.