v78 'Edit only this occurrence' loses Category & Description

[WaltS48]

morat - Is there any way to know if or when the 'bug resolution gurus' are working to resolve a particular bug? It seems they all say 'UNCONFIRMED', 'Unassigned' and 'Priority Not Set' with the reporting 'Opened' date being many months old, as if nothing is being done.

Nothing is being done.

Someone with EDITBUG and CONFIRMBUG privileges has to triage it then confirm it, then it is assigned, patches written, submitted for review, rejected, rewritten, resubmitted until the patch is approved, then uplifted to a build, tested and released.

With the more detailed steps to reproduce you provided in this thread I'll try to get to it in the next couple of days.

I'm not one for using recurring events, so thanks for the detailed STR.

[Code Name]

morat - Is there any way to know if or when the 'bug resolution gurus' are working to resolve a particular bug? It seems they all say 'UNCONFIRMED', 'Unassigned' and 'Priority Not Set' with the reporting 'Opened' date being many months old, as if nothing is being done.

Nothing is being done.

Someone with EDITBUG and CONFIRMBUG privileges has to triage it then confirm it, then it is assigned, patches written, submitted for review, rejected, rewritten, resubmitted until the patch is approved, then uplifted to a build, tested and released.

With the more detailed steps to reproduce you provided in this thread I'll try to get to it in the next couple of days.

I'm not one for using recurring events, so thanks for the detailed STR.

Thank you, Walt!

[WaltS48]

Resolved in Thunderbird 85.0b2.

Still needs an uplift to a 78 version. Probably 78.7.0 due next month.

[Code Name]

Resolved in Thunderbird 85.0b2.

Still needs an uplift to a 78 version. Probably 78.7.0 due next month.

Thank you, Walt. I think your added note to the gurus helped spur things along even though there were numerous people that reported the bug with varying descriptions.

I've been copied on the comments and followed the results. Clearly, these bugs are typically not something that can be fixed with a few minutes of thought and a quick test run. There's definitely a process. And the gurus speak in terms that are totally foreign to me.

I never could determine whether the fix also fixed the category going to 'none' when a repeating event was modified. Maybe you know. Or, I'll just wait for the update to find out.

Again, thanks! You're tops!!!

[Code Name]

The Tb 78.6.1 update (today) fixed the Calendar repeating event (editing a single occurrence) problem.

It appears the fix only applies to newly added repeating events (created after this fix) in which a single event is edited ("Edit only this occurrence"). It appears the fix does not take care of existing (before the fix) repeating events in which a single event [either] had been edited or is now edited. In other words, if you had a repeating event that was created prior to this fix - editing a single repeating event does not work as expected. An existing repeating event that is changed continues to drop the edited description - however the correct category is brought back from the 'None' category when it was broken. Now, only newly created repeating events can have editing of a single occurrence and works as it should.

[According to Magnus Melin; old data would have been lost...]

Walt - Thank you for adding your helpful touch at Bugzilla.

[Code Name]

Whatever was done to fix this problem is now no longer working.

► https://bugzilla.mozilla.org/show_bug.cgi?id=1686466

[Code Name]

Today's update to Tb 78.8.0 has resolved/fixed the ongoing problem (Bugzilla# 1686466) where editing individual occurrences of repeating Calendar Events causes the edited event to lose the edited (changed) description and display a blank description.

https://bugzilla.mozilla.org/show_bug.cgi?id=1686466

This problem was fixed once before with Tb 78.6.1, but apparently update Tb 78.7 made it fail again. Hopefully the fix today with Tb 78.8.0 will resolve the problem permanently.