No writable calendars are configured for invitations

[timur-tabi]

When I add my Google Calendar using CalDav, everything works.

When I add the same calendar using gdata-provider, I cannot accept invitation sent to me via email, even though the calendar is NOT read-only and I can manually add events.

FYI, I had to use the work-around specified in bug #28 to get gdata-provider to work at all.

I'm using Thunderbird 60.9.0 on Ubuntu 19.04.

[yongkhun]

I had no options in the config editor but the reason @Rolf185 changes weren't working for me was #138. After working around that one, things seem to be back to normal (still testing).

Manually adding/creating the following through the config editor solved it for me:

calendar.google.enableAttendees;true
calendar.google.enableEmailInvitations;true
calendar.google.sendEventNotifications;true

After manually adding the 3 configs above, in order to avoid them being removed when restarting Thunderbird, I found the following works for me:

• Goto your thunderbird local profile folder ..\thunderbirdProfile.default\extensions\
• Find the right xpi file of your installed Provider for Google Calendar extension, which might be any of the {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.xpi . If you are not sure which one, just open them one by one using 7-zip and check in the file "manifest.json"
• Open the xpi file with 7-zip (make sure Thunderbird is not running while the xpi file is being opened)
• Edit the file "background.js" and comment out the line: /* await messenger.gdata.purgeLegacyPrefs(); */
• Save and exit 7-zip, and "yes" when prompted whether to update to the archive.

Hope this helps.

[rascasoft]

I had no options in the config editor, but the reason @Rolf185 changes weren't working for me was #138. After working around that one, things seem to be back to normal (still testing). Manually adding/creating the following through the config editor solved it for me:

calendar.google.enableAttendees;true
calendar.google.enableEmailInvitations;true
calendar.google.sendEventNotifications;true

After manually adding the 3 configs above, in order to avoid them being removed when restarting Thunderbird, I found the following works for me:

* Goto your thunderbird local profile folder ..\thunderbirdProfile.default\extensions\

* Find the right xpi file of your installed Provider for Google Calendar extension, which might be any of the {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.xpi . If you are not sure which one, just open them one by one using 7-zip and check in the file "manifest.json"

* Open the xpi file with 7-zip (make sure Thunderbird is not running while the xpi file is being opened)

* Edit the file "background.js" and comment out the line:
  `/* await messenger.gdata.purgeLegacyPrefs(); */`

* Save and exit 7-zip, and "yes" when prompted whether to update to the archive.

Hope this helps.

Many thanks @yongkhun , this workaround works as expected. It would be beneficial to create a pull request to get this included in the official release, but we need first to understand what that purge action was meant to. Maybe @kewisch can share some light on this.

[IanBlakeley]

Done everything suggested above by @rascasoft , checked the changes to calendar extension are still there but sadly the changes to the config file are still removed on a restart. EDIT == deleted the file, re applied changes, seems to be sticking I may have had finger trouble that I could not see.

[adefaria]

Hello Has anyone found a solution for network invitations and not local? thank you

Not a solution but a work-around. While you can't add people to your event through TB you can make the event then go to calendar.google.com and you can add people to the event there.

[felix-seifert]

I applied the settings suggested by @unode and @yongkhun. I added the three suggested config values and edited the relevant .xpi file. When I restart TB, the config values are still set. However, the behaviour of calendar invitations is still the same: "No writable calendars are configured for invitations." Any ideas what else I could try?

[Crandel]

Any ideas what else I could try?

Just set email in calendar properties. It works fine for me

[Daveve200]

I'm relatively new to using Thunderbird and I simply can't believe it, that such a simple action as accepting a calendar invitation via email would steal over 1.5h of my life. And worse: no solution yet. There are lots of outdated posts that talk about TB add-ons that don's even exist anymore, it's surprising that those are still so prominent. - Oh well, I subscribed to the channel. Hope a practical solution comes up soon but the longer these things take, the more cumbersome the use of TB and the more likely that people will resort to large-tech solutions with questionable privacy agreements. (different subject, not to be elaborated on in this thread)

[Rolf185]

Hi,

although I've done some changes to the gdata-provider plugin I'm not using this plugin anymore.

I've defined my Google calendar via caldav:

https://apidata.googleusercontent.com/caldav/v2/account>@<gmail.com/events

For me it's working.

Rolf

Am 04.07.2021 um 13:17 schrieb Daveve200:

I'm relatively new to using Thunderbird and I simply can't believe it, that such a simple action as accepting a calendar invitation via email would steal over 1.5h of my life. And worse: no solution yet. There are lots of outdated posts that talk about TB add-ons that don's even exist anymore, it's surprising that those are still so prominent. - Oh well, I subscribed to the channel. Hope a practical solution comes up soon but the longer these things take, the more cumbersome the use of TB and the more likely that people will resort to large-tech solutions with questionable privacy agreements. (different subject, not to be elaborated on in this thread)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kewisch/gdata-provider/issues/63#issuecomment-873568667, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBC6CPIEFPQDAA4AL5OUZDTWA7NNANCNFSM4LVHP7UA.

[colans]

To make it more formal, any reason to not deprecate this plugin in favour of the CalDAV approach?

[Crandel]

@colans CalDav API is blocked for security issues in my work, so I have no other choices. And editing addon as archive works fine for me. But would be better to create a PR and return this options again

[colans]

Issue created at #190. Please help move that along with PRs, etc. Thanks!

[rstuart]

To make it more formal, any reason to not deprecate this plugin in favour of the CalDAV approach?

As a number of people here and elsewhere have said, CalDAV has an issue: it doesn't dismiss events properly. Every time I use it I get lots of reminders about missed events. I gather people "solve" that but turning notifications for missed events off, but that's not acceptable to everyone.

In the mean time, after manual editing of the config Rolf185's version of this plugin works perfectly.

That aside, what does depreciating it achieve? Unless a maintainer steps up it will die regardless of what you do, and if a maintainer does step up it will continue to live regardless of what you do.

[colans]

@rstuart You're mostly right, but if folks see the issue it may save them some trouble. Your comment about turning off missed events would be helpful over there; please add it.

[ahukkanen]

That aside, what does depreciating it achieve? Unless a maintainer steps up it will die regardless of what you do, and if a maintainer does step up it will continue to live regardless of what you do.

Deprecating would at least make it clearer that this add-on is no longer maintained and therefore should not be used.

The most confusing part to me at least is that the official documentation recommends using this add-on with Google calendar: https://support.mozilla.org/en-US/kb/using-lightning-google-calendar

If that documentation was updated with the CalDAV method, I think it would save a ton of hours in people's productivity not trying to figure out how to fix the issue manually in the add-on but rather relying on the CalDAV method.

As a number of people here and elsewhere have said, CalDAV has an issue: it doesn't dismiss events properly.

To me this is a smaller issue than forking the add-on, manually editing configuration file and trying out different versions of the extension. Even after all that, I never got calendar invitation reply emails to be sent with the gdata-provider add-on (I just replied directly from GMail).

When switching to the CalDAV method, I sure bumped into the events dismiss issue but for me it was only 3 events where I could not dismiss the old reminders. It was a breeze to go edit those 3 events and remove their notifications manually compared to what needed to be done with gdata-provider.

[Crandel]

I think it would save a ton of hours in people's productivity not trying to figure out how to fix the issue manually in the add-on but rather relying on the CalDAV method.

@ahukkanen As I said in my comment I don't have CalDav API at all and cannot rely on it. @yongkhun method works like a charm and I have no problem with calendar events at all. Please don't touch it if you don't use it

[ahukkanen]

@Crandel At least as an official method documented in the official documentation, it should be deprecated because it doesn't work without modifications to the add-on. And if the maintenance is dropped, sooner or later it will be a security issue if people keep relying on 3rd party modifications of the original add-on.

As far as I understood from the discussion, the CalDAV method is the only method right now that works out-of-the-box without modifying any add-on by hand or without modifying any configuration files by hand. I understand that it does not necessarily work for all, but if that is the only option right, I think it should be the preferred one.

[ahukkanen]

It actually seems that there was already a pending revision from Mozilla Support forum user Matt regarding the Google Calendar integration documentation.

I added a note there that this add-on does not work perfectly for Thunderbird v78.11.0 or newer with a link to this issue. Here's the latest revision (at this moment): https://support.mozilla.org/en-US/kb/using-lightning-google-calendar/revision/225291

[mthskarin]

This issue has sadly has on and off, stolen many productive hours of my time over the years. I find it strange that it it so hard to get a cloud based calender to work with Thunderbird. (kind of a "must have" for a digital worker).

I highly appriciate every effort from all developers that makes Thunderbird and its ecosystem work. It is truly amazing to have an open source option outside Exchange and Tech giants.

That said, I do I second that the Google Calendar plugin should be depricated until this issue is solved, for the sake of saving valuable productive hours of people's time.

The CalDev workaround worked for me (big thanks to @rolbr for sharing it).

[kewisch]

I've identified the cause for this, please expect it to work again in Provider 91.0.2

[Gwalior-84]

I've identified the cause for this, please expect it to work again in Provider 91.0.2

Thanks @kewisch Is Provider 91.0.2 available? The latest version available in github is 91.0.0 and on the Thunderbird Add-ons page is 91.0.1. (How does the Thunderbird Add-ons page get a more recent version that github?)

[RickKukiela]

If anyone else stumbles upon this its important to note that you cannot use a "group" calendar for accepting ICS emailed invites. It took a bit of trial and error but I figured out that only the default calendar for the google account can be configured this way and has the "Email" drop down when editing the settings in lighting. In google calendars, on the site, if you edit the calendar the calendar ID shown there will be your "account email" (even if its not a gmail address) and that calendar can be used correctly with your mail. The other calendars you add or are shared to have some kind of unique character string + @group.calendar.google.com - If your calendar has an ID like this it will not work. You can rename the main calendar that has the ID that matches your account email address to whatever you want and it will work fine. I'm not sure if this is covered anywhere in the docs for the connector, but if it isn't, it should be. Also the interface should have a note about this where the email address drop down would normally show up for compatible calendars informing the user that the calendar they are looking is not compatible with inbox invites for the reasons I have stated above with the above information. Would have saved me an hour or two of dicking around with this trying to figure out why I couldnt use the calendar I wanted with my work email...

My final work around was to create a google account with my work email then I used that "main / default" calendar that had my work email as the ID. I then shared that calendar with my main / personal gmail account so I could see my "work" calendar on my home computer and personal devices and still have it work with my thunderbird client the way I have always wanted... Its been 15 years or so and I finally have an integrated work calendar...

[mauromol]

Any chance to get this fix to a version compatible with Thunderbird 78.x? No 91 version available yet on Ubuntu 20.04...

[IanBlakeley]

Any chance to get this fix to a version compatible with Thunderbird 78.x? No 91 version available yet on Ubuntu 20.04...

I had this issue as a Mint user. in the end jumped off the lagging version in the repositories and I now use the direct update path from Mozilla

[MartinX3]

Any chance to get this fix to a version compatible with Thunderbird 78.x? No 91 version available yet on Ubuntu 20.04...

I switched from mint to arch linux because of the ubuntu lts update policy. (I created issue tickets about backporting all the time before, because otherwise they ignored new versions)

[Crandel]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

[MartinX3]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

[Crandel]

When just use Ubuntu Mozilla Security ppa it has the latest version

[mauromol]

I think we're going off topic here. The problem is not that all the world must want to get the latest version of Thunderbird at all costs (I don't feel it is necessary for me to upgrade to Thunderbird 91 right now from a feature point of view), but rather that there still are fully supported Thunderbird installation scenarios where this severe bug of gdata-provider currently stands.

So, question is again: is there any hope to get a backport to support Thunderbird 78 or not?

Of course, the maintainer may just respond "no, it's not planned" and I would respect it. After that, it will be my choice to perform all the necessary actions required to update Thunderbird with any of the multiple options there are, or prefer to just wait for Ubuntu to upgrade their official packages, if I can live with this problem meanwhile. It's just a matter of personal priorities.

[Crandel]

In 91 version there are no needs for this addon anymore, it will automatically pick up your calendar during setup with full synchronization

[MatthewVernon]

FWIW, with Thunderbird 78 (and presumably later), I found these instructions on adding CalDAV support sufficient to get calendar support working without this plugin; mentioning it here in case that's useful...

[Ryushin]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

I just download the Thunderbird tar ball, put it in /opt, change the ownership to myself and it auto updates like normal.

Though I allowed Thunderbird to update to the latest version and the readability of the fonts being used was terrible, so I downgraded until I have time to get that sorted.

[MartinX3]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

I just download the Thunderbird tar ball, put it in /opt, change the ownership to myself and it auto updates like normal.

Though I allowed Thunderbird to update to the latest version and the readability of the fonts being used was terrible, so I downgraded until I have time to get that sorted.

That's a bad practice. /opt needs to be owned by root:root and software only updated by the administrator (by using sudo). And never execute a software with sudo just to workaround filesystem permissions.

[Ryushin]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

I just download the Thunderbird tar ball, put it in /opt, change the ownership to myself and it auto updates like normal. Though I allowed Thunderbird to update to the latest version and the readability of the fonts being used was terrible, so I downgraded until I have time to get that sorted.

That's a bad practice. /opt needs to be owned by root:root and software only updated by the administrator (by using sudo). And never execute a software with sudo just to workaround filesystem permissions.

/opt is owned by root, /opt/thunderbird is owned by me.

[MartinX3]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

I just download the Thunderbird tar ball, put it in /opt, change the ownership to myself and it auto updates like normal. Though I allowed Thunderbird to update to the latest version and the readability of the fonts being used was terrible, so I downgraded until I have time to get that sorted.

That's a bad practice. /opt needs to be owned by root:root and software only updated by the administrator (by using sudo). And never execute a software with sudo just to workaround filesystem permissions.

/opt is owned by root, /opt/thunderbird is owned by me.

Yes, that's a bad practice.

[Ryushin]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

I just download the Thunderbird tar ball, put it in /opt, change the ownership to myself and it auto updates like normal. Though I allowed Thunderbird to update to the latest version and the readability of the fonts being used was terrible, so I downgraded until I have time to get that sorted.

That's a bad practice. /opt needs to be owned by root:root and software only updated by the administrator (by using sudo). And never execute a software with sudo just to workaround filesystem permissions.

/opt is owned by root, /opt/thunderbird is owned by me.

Yes, that's a bad practice.

Yea, well, it is not bad practice. /opt/tomcat is owned by tomcat:tomact, and many other software packages do it the exact same way. Having /opt/thunderbird set to 777 is wrong. Having it owned by me is correct.

Though for a multi user system a little cron job can have it auto upgrade by downloading and installing the latest version on a weekly basis:

#!/bin/bash
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin

cd /tmp/
wget -O ThunderbirdSetup.tar.bz2 "https://download.mozilla.org/?product=thunderbird-latest&os=linux64&lang=en-US"
tar xjf ThunderbirdSetup.tar.bz2 -C /opt/
chmod -fR 755 /opt/thunderbird

[MartinX3]

Just use Thunderbird 91.3 via AppImage on Ubuntu/Mint. I also use it works fine

Sadly solutions like AppImage, Snap, Flatpak, etc are all having the (dis)advantage to included all needed software libraries. So if a library needs a minor update from x.y.1 to x.y.2 because of a security bug, you won't get the update via your regular system updates. Instead you need to wait until a new Image for the software got created.

I just download the Thunderbird tar ball, put it in /opt, change the ownership to myself and it auto updates like normal. Though I allowed Thunderbird to update to the latest version and the readability of the fonts being used was terrible, so I downgraded until I have time to get that sorted.

That's a bad practice. /opt needs to be owned by root:root and software only updated by the administrator (by using sudo). And never execute a software with sudo just to workaround filesystem permissions.

/opt is owned by root, /opt/thunderbird is owned by me.

Yes, that's a bad practice.

Yea, well, it is not bad practice. /opt/tomcat is owned by tomcat:tomact, and many other software packages do it the exact same way. Having /opt/thunderbird set to 777 is wrong. Having it owned by me is correct.

Though for a multi user system a little cron job can have it auto upgrade by downloading and installing the latest version on a weekly basis:

#!/bin/bash
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin

cd /tmp/
wget -O ThunderbirdSetup.tar.bz2 "https://download.mozilla.org/?product=thunderbird-latest&os=linux64&lang=en-US"
tar xjf ThunderbirdSetup.tar.bz2 -C /opt/
chmod -fR 755 /opt/thunderbird

You should use ~/.local/opt for your user application.

[bbceg]

FWIW, with Thunderbird 78 (and presumably later), I found these instructions on adding CalDAV support sufficient to get calendar support working without this plugin; mentioning it here in case that's useful...

Thanks for this, those instructions worked a treat on 91.4.1 for two calendars. The only downside seems to be a lack of tasks but I guess I can use the addon for that.

[ElizaZadura]

I have the same issue. Found a solution!

Tools -> Options -> Advanced -> Config Editor Set calendar.google.enableEmailInvitations to True Close thunderbird, reopen, should work :) Also, go to Calendar, right click, select properties and make sure an email address is associated with the calendar. Then should be writable for other email accounts, not just the default, as well.

This still worked for me (TB 91.13.0). The option wasn't there, but got saved when I added it, set to true. Only one gmail account though.

[af7567]

Adding the calendar.google.enableEmailInvitations manually in TB 102 doesn't work for me any more.

[AGI-chandler]

@kewisch still a problem with TB 102. calendar.google.enableEmailInvitations=true and I also tried adding my email to another calendar, looking at the config editor and noticing the calendar.registry.<uuid>.imip.identity.key was updated to id# with #=1 in my case. so I tried setting the calendar.registry.<uuid>.imip.identity.key for my google calendar to id1 also but it didn't help. Hope you could please fix this ASAP as it's interfering with my work.

[AGI-chandler]

Ok I have 2 google accounts added, with 3 calendars from the 1st acct and 1 calendar from the 2nd. 2/3 of the calendars from the 1st acct have the option to assign an email to it, while the 3rd calendar plus the 1 calendar from the 2nd acct don't have the option to assign an email. I compared all the calendar.registry.* settings and there wasn't anything different between them aside from the obvious URI's and names and whatnot, but nothing that indicated why 2 of them allowed an email to be assigned and 2 of them didn't.

But! I found a solution! @af7567 For the calendar(s) that didn't allow assigning an email address, I went to https://calendar.google.com directly. On the left side went to the calendar settings (3-dots menu > Settings and sharing), then exported the calendar. It sent me a zip file with an ical file inside. I extracted the ical file then went back to Google and just imported it back into my calendar (on the same page, Import & Export in the upper left (might have to create a new calendar first)). So now you should have two copies of the same calendar. Now go back into TB Calendar and add a new Google Calendar, select your existing account and click Find Calendars, it should show both of them now, put a checkmark in the new calendar and click Subscribe. With the new calendar you should be able to assign an email to it! If everything looks ok you can remove the old duplicate calendar from TB and delete it from your Google acct.

My guess is that our current calendars must be in some legacy format that is triggering this bug? Creating a new google calendar may have updated it with the latest metadata or something. I still have calendar.google.enableAttendees, calendar.google.enableEmailInvitations, and calendar.google.sendEventNotifications defined and set to true. Just tried deleting all three of those preferences and restarting TB, it didn't change or delete my ability to assign an email to my calendars, so perhaps those preferences are now meaningless. Hope it works for you! Let us know...

[af7567]

@AGI-chandler I had no idea there was even meant to be an option to assign an email address to the calendar :) I have never seen that in the calendar properties before. But after upgrading Thunderbird to 102.4 today I had the option to assign an email address to one of my Google calendars and luckily it is the one I would like my invitations to go to. I don't have an email selection box on my other 2 calendars though for some reason.

[pedjas]

I stumbled too onto this issue. Thunderbird 102.11.0. Unbelievable that this issue is so old and not resolved yet.

Fix that worked for me with Google account:

Add new Calendar (click + on Calendar List) Select option On the Network Enter Google email address and click on Find Calendars. Follow the procedure of authentication.

You will be offered to import calendar, do it.

New calendar allows adding event by clicking on invitation.

If you are adding calendar account that already exists in your Thunderbird just make sure you name them so you now which is which as they will both show up.

Disable old account until you are sure new one works.

When sure you may delete old account.

[xsonic]

I have set calendar.google.enableEmailInvitations=true (don't know if necessary). For me, it only started working after I deleted my local thunderbird calendar. I exported my TB calendar, and imported it into Google.

After deleteing all local TB calendars and selecting my email for the google calendar (Rightclick on calendar -> Properties -> Email), it started working and asking me, into which google calendar I want to import.

[KindlyThrive]

Strange, I have had this issue in Thunderbird for ages. Well, for the past few months it started working and it was great. Now with the most recent update, no more. :( I use 3 google calendars on 3 accounts and I have 4 more available. I wish it would at least just give us the calendar event file so we could import it. Or allow us to drop and drag the email into the calendar and understand what we wanted to do. :(