When editing a repeated calendar event and choosing "edit only this occurrence" the edit is not saved.
Categories
(Calendar :: Dialogs, defect)
Tracking
(Not tracked)
People
(Reporter: zam4, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
When editing a repeated calendar event and choosing "edit only this occurrence" the edit is not saved. I opened my calendar, double clicked the event (which is a repeated event), chose edit only this occurrence, then edited the title by adding a few words and saved. Initially it looks like it saved but when closing out then reopening Thunderbird again, the changes to that event are gone.
Actual results:
Changes appear to save until you close Thunderbird and open it back up. When you do that the change in the event is gone and it reverts back to the original.
Expected results:
The changes should have stayed in that particular event. They used to until it updated to the latest version.
|
||
Comment 1•4 years ago
|
||
Which version are you using? Bug 1664731 was fixed in 78.6.1
|
||
Updated•4 years ago
|
|
||
Comment 3•4 years ago
|
||
I'm hitting the same issue, with Thunderbird 78.6.1 (Linux x86-64). I also did find bug 1664731, thought it should be fixed in 78.6.1, but had to conclude it is actually not. In fact, my testing suggests that the bug was fixed but only partially.
How to reproduce:
- Create a new event in a local calendar. Set the title, location, time to 2 PM. Set repeat to "Weekly" until "Forever". Save and close.
- Edit the second occurrence of this event (Edit only this occurrence). Change the location, change the time to 3 PM. Save and close.
- Edit the third occurrence of this event (Edit only this occurrence). Change the location, change the time to 4 PM. Save and close.
- Everything looks OK. Now close Thunderbird and start it again. The original version of the event is OK, the second occurrence is OK as well (changes have been taken into account). But the third occurrence is wrong, it is back to the original version of the event, the changes specific to that occurrence have not been saved.
So basically it seems like bug 1664731 was fixed but only if there's a single modified occurrence of a repeating event. If there are 2 or more, then the bug still exists.
If you need more testing from me, just let me know.
|
||
Comment 4•4 years ago
|
||
reproduced in 78.7.0
|
|
||
Comment 5•4 years ago
|
||
(In reply to andycher11 from comment #4)
reproduced in 78.7.0 windows 10 20H2
|
|
||
Comment 7•4 years ago
|
||
zam4, can you please check again with the latest Thunderbird release (78.9.1) and report back?
|
|
||
Comment 8•4 years ago
|
||
anfycher11 and Jean, can you please check again with the latest Thunderbird release (78.9.1) and report back?
I'm running 78.9.1 and I am now able to edit "just this occurrence" and the changes now stay after program restart. Thanks!
|
|
||
Comment 10•4 years ago
|
||
I will test as soon as version 78.9.1 hits the openSUSE Leap 15.2 repository. For the time being I can only report the test results of my sister (on behalf of whom I commented here originally):
"Changes of time, title, description are properly saved. However, if only changing the time or the title, the description is lost."
Once I'm able to test, I will report here if my conclusions are the same or not.
|
|
||
Comment 11•4 years ago
|
||
I have done some testing this morning (78.9.1 on openSUSE Leap 15.2). I can confirm my sister's findings. The bug I described in comment #3 is fixed, so I am able to customize (Location, Time) more than one occurrence of a recurring event and these changes stick through restarting the application. However, after closing Thunderbird and opening it again, customized occurrences no longer have the Description they should have inherited from the original event. Problem happens for both old events which I created with 78.6.1 and new events which I created today with 78.9.1. Note that if I also customize the Description for a given occurrence then the change does stick properly.
For clarity, how to reproduce the remaining bug:
- Create a new event in a local calendar. Set the time to 2 PM, give it a title, location, description. Set repeat to "Weekly" until "Forever". Save and close.
- Edit the second occurrence of this event (Edit only this occurrence). Change the time to 3 PM, leave everything else unchanged. Save and close.
- Everything looks OK. Now close Thunderbird and start it again. Open the second occurrence of the event. Title and time are OK, however location and description are both empty. As you did not change them when customizing the occurrence, they should have been copied/inherited from the original event.
Thank you for your work so far, things are improving even though not everything is working as it should yet. If you need more testing from me, just let me know.
|
||
Comment 12•4 years ago
|
||
(In reply to Jean DELVARE from comment #11)
I can confirm that exact behaviour with 78.10.0 in Debian.
|
||
Comment 13•4 years ago
|
||
I can confirm this behavior on TB 78.10.1 it works on current Beta 89.0b4
|
|
||
Comment 14•4 years ago
|
||
(In reply to Jean DELVARE from comment #11)
just tested 78.11.0 in debian, that particular problem is still there.
Thanks
|
|
||
Updated•4 years ago
|
|
|
||
Comment 15•4 years ago
|
||
|
|
||
Updated•3 years ago
|
|
|
||
Comment 16•3 years ago
|
||
hi, still there in 78.14.0
|
|
||
Comment 17•3 years ago
|
||
Any hope to get a complete fix for this bug?
|
|
||
Comment 18•3 years ago
|
||
hi, I'm happy to report that this bug seems solved in 91.4.1 (debian sid).
I followed the procedure detailed in comment #11, tried to modify different occurences of the event via several means (right click edit, double click edit, drag&drop), and in all cases the location and description were kept.
|
|
||
Comment 19•3 years ago
|
||
I can confirm that the bug described in comment #11 is fixed for me as well (Thunderbird 91.7.0, openSUSE Leap 15.3/x86_64). This bug can be closed as FIXED, thank you very much.
|
|
||
Comment 20•3 years ago
|
||
Resolving as WORKSFORME per comment#18 and comment#19.
Description
•