User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5) KHTML/3.5.8 (like Gecko) Build Identifier: 2008021219 Hi, I tried out the latest nightly to get some experience with the new offline caching support. I use the SOGo connector http://www.inverse.ca/english/contributions/sogo_connector.html to sync my contacts and calendars with thunderbird/lightning. Unfortunately the offline caching support doesn't work as expected. When I delete an event on the server, it is still visible in lightning after syncing with the server. I assume this is a bug in the offline cache implementation since this doesn't happen if caching is disabled. The event can't even be deleted manually in lightning. Please fix this bug before 0.8 release. Regards, Ruben Reproducible: Always Steps to Reproduce: 1. connect with sogo-connector to a caldav calendar on the network 2. enable offline caching for this calendar 3. create an event in this calendar & sync with the server 4. delete the previously created event on the server 5. sync with the server Actual Results: on the server deleted event is still visible in lightning manual deletion fails Expected Results: event should get deleted
I don't know what sogo-connector adds to caldav, but the current caldav provider code does not provide changelog based synchronization. That way, the cached calendar code always does a full sync  removing the local calendar  before retrieving and adding the *entire* remote calendar. I verified the above works with a local ICS file. Could you please remove the SoGo stuff and try that again? Could someone else with a caldav store try confirm this bug, please?  <http://mxr.mozilla.org/mozilla1.8/source/calendar/base/src/calCachedCalendar.js#262>  <http://mxr.mozilla.org/mozilla1.8/source/calendar/base/src/calCachedCalendar.js#171>
Not going to block on this unless it gets confirmed. Please renominate, once it gets confirmed.
Flags: blocking-calendar0.8? → blocking-calendar0.8-
This works properly for me using current nightly against Bedework, without the connector (takes a few seconds, but it works). I'm thinking this is an interop issue with SOGo such as has been seen in bug 418050, and am closing the bug on that assumption. Reporter, if you are using something other than SOGo or have reason to believe that this is a Mozilla bug rather than a SOGo one, please feel free to reopen. ->INVALID
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.