GNOME Bugzilla – Bug 693698
Meeting invitation calendar lookup thinks of writeable CalDAV as readonly
Last modified: 2015-02-18 15:06:24 UTC
The itip-formatter searches for meeting invitation basically in all configured calendars, it only skips those, which are reported as read-only. I found out yesterday, that the EClient changes broke this in some way, that my CalDAV calendar is reported as readonly, thus the search is skipped in there, but the calendar contains this invitation. This is mostly visible when opening the calendar for the first time, like: a) close evolution and all other evolution processes (including evolution-calendar-factory) b) run evolution in mail and pick a meeting invitation, which is in writeable CalDAV calendar; the invitation will start evolution-calendar-factory and will open the CalDAV calendar for the first time. c) when itip-formatter checks writeability, the EClient reports it read-only While this can be related to bug #693464, I rather filled a new bug report.
Just a quick check on this bug. As an user I run into a very similar issue all the time. Not certain it is identical but "CALDAV_DEBUG=all" doesn't seem to work so I can't help debug. Any progress per chance?
One note: even when the CalDAV calendar is said to be readonly, I can still right-click "Import to Calendar" and import into that calendar.
The CALDAV_DEBUG=all set on evolution's start is for "Find calendars" from the calendar properties. To get information from actual server communication one might run evolution-calendar-factory with this set. In any case, it's not an issue with CalDAV server as such, it's an issue with evolution/evolution-data-server. I do not know anything about progress on this, a workaround might be to go to a Calendar view, enable the calendar, then return back to Mail view and re-select the message with invitation. The Calendar view keeps calendar opened, thus the Mail view gets quicker response with already opened calendar which is properly identified as writable.
I spent some time trying to investigate this, and even I still cannot reproduce this reliably, I get the error couple of times. After some investigation, I get this order of calls. The first one is when it works properly: e_cal_client_connect: GDBusProxy::notify: writable val:0 GDBusProxy::g-properties-changed: changes: '{'Writable': <true>}' invalids[0]:'(null)' GDBusProxy::notify: writable val:1 e_cal_client_connect_finish: That shows how the ECalClient is opened and before its opening phase is finished, the GDBus property is properly updated. The second call order differs: e_cal_client_connect: GDBusProxy::notify: writable val:0 e_cal_client_connect_finish: GDBusProxy::g-properties-changed: changes: '{'Writable': <true>}' invalids[0]:'(null)' GDBusProxy::notify: writable val:1 That shows that the ECalClient is opened, a false notification about property change is received (the same as in the first call order), but then the opening phase is finished, and only after that the GDBus property is properly updated, but it is too late for the caller. From that I'd say that all the behaviour depends on the order of GDBus signal delivery on the client side, because the server side always does this correctly, which means that before the opening phase is finished on the server side, the property change is properly notified, and only then is called the corresponding 'complete' function. (These D-Bus interfaces are auto-generated with gdbus-codegen.)
Ryan, could you comment whether my observation (and description) above makes sense, and whether we can do anything with it in evolution(-data-server), please? The idea is that we should always get object's property changes before we finish the actual 'open' call, thus the caller on the client side gets up-to-date information, instead of a stale information, which will be changed "a second later".
I fixed this for 3.13.90 development version. The change will be included in the 3.14.0 evolution release, which will be out together with GNOME 3.16.0.