GNOME Bugzilla – Bug 721712
Writeable calendars can report as read-only after open
Last modified: 2015-02-18 15:04:51 UTC
I have a number of google calendars configured in Evolution 3.10.3 but they all seem to be read-only even though I can write to them from other places, such as my Android phone. When I try to create a new event in such a calendar I get a warning above the editing fields that reads: Event cannot be edited, because the selected calendar is read only I don't even know how one would intentionally set a google calendar read-only so I'm not convinced this is a local configuration issue.
Make sure you have Google calendar selected, not Birthdays & Anniversaries (evo sometimes displayed the calendar source incorrect;y, so I had to re-select the calendar)
Of course.
I tried to reproduce this, but no luck. I configured a Google calendar as CalDAV, then also as a Google calendar, both directly in evolution, but also as a Gnome Online Account, with OAuth2 authentication. All three works fine for me. I do have them setup for Alarm notifications. It's possible you face a variant of bug #693698, though.
Do you still face this issue, please? I do not ask to update to 3.10.4, which was released only today, I do not see anything directly related to this issue there. I rather ask if you can still reproduce this on will, or whether it happens randomly to you, the same as to me (even I didn't see this for a long time).
Yes, I still have this issue and it's (annoyingly) 100% reproducible.
*** Bug 727661 has been marked as a duplicate of this bug. ***
So, this gotten even worse, to the point that I am not getting any data from Google Calendar on machines that are using a proxy.
(In reply to comment #7) > So, this gotten even worse, to the point that I am not getting any data from > Google Calendar on machines that are using a proxy. It's a different issue, maybe anything with bug 724316?
Tristan told me that the GDBusProxy property change notifications are not sent reliably to the client, especially when it is in the middle of a GDBus method call, thus he suggested to pass current property values in the response to the "open" method call. I managed to reproduce this issue on one of my calendars and this approach fixes the issue. I cannot commit to the stable branch due to D-Bus interface API change. Created commit 033215f in eds master (3.13.4+) [1] [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=033215f
I caused a reference imbalance on EBook/CalClient instances with the above patch, which led to memory leaks in certain situations. Fidencio spot it. This is fixed now with: Created commit 5d41935 in eds master (3.13.4+) [2] [2] https://git.gnome.org/browse/evolution-data-server/commit/?id=5d41935
As reported at bug #740208, this could still happen, a writable calendar could be shown as read-only, when it was opened for the second time. I extended (actually simplified) the previous solution with: Created commit 8b2746f in eds master (3.13.9+) [3] [3] https://git.gnome.org/browse/evolution-data-server/commit/?id=8b2746f
Yet another issue found, this time in evolution. When an EClient descendant was opened synchronously, it remembered a thread default main context from that call, which was a main context related to an EAsyncClosure, which doesn't live for long, but the EClient still used it to notify about D-Bus object's property changes. I made changes in Evolution to avoid this failure. I didn't change EAsyncClosure and its routines, it might need more thorough thinking and changes in the code. Created commit 1ad40c6 in evo master (3.13.90+) [4] Created commit 0e6ad40 in evo evolution-3-12 (3.12.11+) [4] https://git.gnome.org/browse/evolution/commit/?id=1ad40c6
*** Bug 741017 has been marked as a duplicate of this bug. ***