GNOME Bugzilla – Bug 647698
Selected calendar doesn't authenticate after offline/online
Last modified: 2017-08-31 13:35:02 UTC
When you shut down Evolution and start it again, Evolution remembers which calendar was selected in the sidebar, and it selects it again when you restart. I'd call this the "default calendar" if that term didn't mean something else, so let's call it the "selected calendar". When Evolution starts up, this calendar is opened *twice*. There are *two* calls to e_cal_new() and e_cal_open() for it. One of them is marked as the 'default' with a call to e_cal_model_set_default_client(). And at about line 248 of evolution/calendar/common/authentication.c, it calls e_cal_set_auth_func() to *clear* the authentication callback function. Now I click in the bottom left-hand corner to take Evolution offline and then online again. Evolution now calls e_cal_open() for all calendars again, including both instances of the selected calendar. But for the one that's actually marked as the default, it *fails* to open it again. Because at about line 1217 of e-cal.c, in open_calendar(), it sees that the auth_func is NULL and thus it fails to authenticate. Now, when I try to add a new meeting in the calendar, it *fails* with the message 'Default client not loaded'. I can work around this by selecting a different calendar in the side-bar, then selecting the original one again. Except that it *doesn't* actually select the original calendar; it selects the *other* instance that it opened of the same calendar. And it didn't clear the ->auth_func for that one, so that one *did* manage to get re-opened when it came back online again. WTF?
I cannot reproduce with a CalDAV folder as the "selected folder"; only EWS. I don't know why. It looks like the 'auth-required' signal is not emitted on the CalDAV folders after offline/online, so it never even *tries* to reauthenticate; it just remains in the LOADED state all the time.
Created attachment 185906 [details] [review] Untested patch Try this. The comments in the patch allude to why I was clearing the authentication function previously, but this works around it. It boils down to e_cal_set_auth_func() not providing a way to free the closure that you pass it. In the future, once password lookup in the keyring is simplified, calendar backends ought to be able to look up passwords for themselves and only emit "auth-required" if the keyring doesn't have it, or if the password is wrong. They shouldn't have to lean so hard on clients for this.
That seems to work here (tested on 2.32). Thanks. Still kind of odd that we're opening two clients for the same calendar instead of only one, and that changing away from the calendar that's selected when we start up, and back to it, will select the *other* instance of it. But I suspect you're already as keen on cleaning that up as I am, so there's no need to draw too much more attention to it :)
Patch committed to master and gnome-3-0 branches: http://git.gnome.org/browse/evolution/commit/?id=760c438e670e4ebe01c5431779628ed3a3189b76 http://git.gnome.org/browse/evolution/commit/?h=gnome-3-0&id=9045eb0026c91ee2174b06090d6c978299854394 I'll let you pluck it for gnome-2-32 and decide if that's enough to close the bug, given the duplicate calendar connection issue still exists.
Comment on attachment 185906 [details] [review] Untested patch (In reply to comment #4) > Patch committed to master and gnome-3-0 branches: Updating patch status accordingly. > I'll let you pluck it for gnome-2-32 and decide if that's enough to close the > bug, given the duplicate calendar connection issue still exists. dwmw2: Ping?
Many things changed meanwhile, notably EClientCache being used on the evolution side for several versions (avoiding opening multiple EClient instances for one source), thus I'm closing this bug report.