GNOME Bugzilla – Bug 672398
CalDAV backend doesn't respect "Copy for offline" option
Last modified: 2012-04-24 12:47:37 UTC
Description of problem: when CalDAV URI is unreachable, the calendar can't be enabled in spite of enabled offline cache. This makes offline cache pretty much useless. Version-Release number of selected component (if applicable): evolution 3.2 on Fedora 17 How reproducible: always Steps to Reproduce: 1. have a CalDAV calendar with Copy Calendar for Offline Use (or so) checkbox checked 2. turn on Offline Mode 3. quit Evolution, restart e-calendar-factory/evolution-data-server, start 4. reenable calendar Actual results: calendar can not be enabled again Expected results: calendar will be enabled Additional info: when user makes changes to calendar contents, he/she should be warned that it can not be pushed to calendar right away. During actual push of the changes, user should be asked how should be any conflicts resolved.
I can reproduce it as well in Evo 3.2 in Fedora 16.
The CalDAV backend doesn't support real offline handling. The most it can show the cached events in offline mode, like On The Web calendars work, and when the server gets reachable then it'll use it in writeable mode again (if available for the user by server principals). Some such code is available in Fedora, thus enabling in offline mode is considered as a typo in the URL (not necessary offline mode initiated by a user, but kinds like VPN unexpected disconnect and such). For proper offline handling in CalDAV see bug #633698
Created attachment 212689 [details] [review] eds patch for evolution-data-server; I just realized that the CalDAV backend doesn't respect "Copy for offline" option, which actually makes CalDAV calendars read-only open in offline mode. Note this offline mode is harder to achieve in 3.4.0+, because the evolution-calendar-factory doesn't listen for offline forced states from evolution, but listens to NetworkManager notifications instead (through GLib, thus it can be even other network monitor software). This change makes sense in multi-client environment, where the factories of evolution-data-server belong.
Created commit fbe6f72 in eds master (3.5.1+) Created commit c31a9ce in eds gnome-3-4 (3.4.2+)