Dismissing a notification for a recurring event deletes the recurrence-specific event description

[binki]

I use recurring events to mass create events that are weekly. However, prior to each week, I receive recurrence-specific information which I edit into each individual event on Google Calendar. However, when a notification appears in Thunderbird and I press Dismiss, the recurrence-specific event description is deleted.

Fortunately, I have this data available elsewhere. But I really want to be able to store data in my calendar and still access it from Thunderbird and see notifications without risk of data loss. So please fix this or disable writing to events upon dismissing notifications.

Thanks!

[kewisch]

Can you enable debugging and share what happens on the dismissal?

[dnet890]

I have the same issue with Thunderbird 128 esr. and when I click the X button or submit changes anyway it does not worked. May I know how to enable debugging?

[kewisch]

https://github.com/kewisch/gdata-provider/wiki#enabling-debugging

Please only comment here if it is specifically about the description going away. If it is about it not working generally please see the pinned issue.

[binki]

Can you enable debugging and share what happens on the dismissal?

I have attached the log at console-export-2025-3-23_17-16-40.txt. I created a specific account and profile to test this feature so I haven’t bothered to redact anything. This is from version 128.5.2.

I created a weekly recurring event which occurs Monday, Tuesday, Wednesday, Thursday, Friday. For the first three, I manually edited in these descriptions:

• The first one!
• The second one!
• The third one!

After pressing Dismiss in Thunderbird for a notification for the first one, Thunderbird still displays “The first one!” in the description of the event. But Google Calendar (for this account checked via web but I normally notice on the Android Google Calendar app for my real account) has the description cleared.

It does look like the second line in the following is suspicious because it edits the master item instead of the recurrence item. This seems to, as far as I can tell, wipe away all recurrence-specific edits for everything sharing the same master event:

17:16:15.826 Calendar: [calGoogleCalendar] Modifying item Lunch (master item) gdataCalendar.sys.mjs:487:9
17:16:15.829 Calendar: [calGoogleRequest] Requesting PUT https://www.googleapis.com/calendar/v3/calendars/gcaltest00234234%40gmail.com/events/23u5a275mpagksm5dl5ts99a4c?sendUpdates=none gdataRequest.sys.mjs:216:16
17:16:15.829 Calendar: [calGoogleCalendar] Setting Upload Data (application/json; charset=UTF-8):
{"start":{"dateTime":"2025-03-24T12:00:00","timeZone":"America/Detroit"},"end":{"dateTime":"2025-03-24T13:00:00","timeZone":"America/Detroit"},"summary":"Lunch","location":"Earth","status":"confirmed","reminders":{"overrides":[{"method":"popup","minutes":600},{"method":"popup","minutes":1440},{"method":"popup","minutes":30}],"useDefault":false},"extendedProperties":{"private":{"X-MOZ-LASTACK":"2025-03-23T21:16:15Z"}},"recurrence":["RRULE:FREQ=WEEKLY;BYDAY=MO,WE,FR,TU,TH;UNTIL=20250624T035959Z;WKST=SU"]} gdataRequest.sys.mjs:282:16
17:16:15.830 Calendar: [calGoogleCalendar] Sending request headers: ({}) gdataRequest.sys.mjs:311:16
17:16:16.106 Calendar: [calGoogleRequest] Clock skew is 3 seconds gdataRequest.sys.mjs:387:16
17:16:16.107 Calendar: [calGoogleCalendar] Request PUT https://www.googleapis.com/calendar/v3/calendars/gcaltest00234234%40gmail.com/events/23u5a275mpagksm5dl5ts99a4c?sendUpdates=none responded with HTTP 200 gdataRequest.sys.mjs:394:14

Maybe the PUT needs to include all recurrences instead of just the master or you need something like a PATCH request.

[kewisch]

The beta uses PATCH, can you try and see if it works more like you expect?

https://kewisch.github.io/gdata-provider/beta.html

[github-actions[bot]]

It looks like we haven't heard back on this issue, therefore we are closing this issue. If this problem persists in the latest version of Thunderbird and the Provider for Google Calendar, please re-open this issue.