MozillaZine


v78 'Edit only this occurrence' loses Category & Description

For discussing the Mozilla Calendar, Sunbird and Lightning projects.
WaltS48

User avatar
 
Posts: 4587
Joined: May 7th, 2010, 9:38 am
Location: Pennsylvania, USA

Post Posted November 25th, 2020, 4:04 pm

Code Name wrote: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.
Linux Desktop - AMD Athlon(tm) II X3 455 3.3GHz | 8.0GB RAM | GeForce GT 630
Windows Notebook - AMD A8 7410 2.2GHz | 6.0GB RAM | AMD Radeon R5

Code Name

User avatar
 
Posts: 159
Joined: December 23rd, 2019, 1:53 pm
Location: Dallas, TX

Post Posted November 25th, 2020, 5:17 pm

WaltS48 wrote:
Code Name wrote: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!
Politicians and Diapers must be changed often for the exact same reason...

WaltS48

User avatar
 
Posts: 4587
Joined: May 7th, 2010, 9:38 am
Location: Pennsylvania, USA

Post Posted December 22nd, 2020, 3:05 pm

Resolved in Thunderbird 85.0b2.

Still needs an uplift to a 78 version. Probably 78.7.0 due next month.
Linux Desktop - AMD Athlon(tm) II X3 455 3.3GHz | 8.0GB RAM | GeForce GT 630
Windows Notebook - AMD A8 7410 2.2GHz | 6.0GB RAM | AMD Radeon R5

Code Name

User avatar
 
Posts: 159
Joined: December 23rd, 2019, 1:53 pm
Location: Dallas, TX

Post Posted December 22nd, 2020, 7:00 pm

WaltS48 wrote: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!!! =D>
Politicians and Diapers must be changed often for the exact same reason...

Code Name

User avatar
 
Posts: 159
Joined: December 23rd, 2019, 1:53 pm
Location: Dallas, TX

Post Posted January 12th, 2021, 9:40 am

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. =D>
Politicians and Diapers must be changed often for the exact same reason...

Return to Calendar


Who is online

Users browsing this forum: No registered users and 2 guests