User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20100722 Firefox/3.6.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/20100802 Lightning/1.0b3pre Thunderbird/3.1.2 If I create a new calender which consists of an ics-file on a server might get overridden with old data on change. Reproducible: Always Steps to Reproduce: 1. Create calendar in lightning which resides on a server 2. create an event a on client 1 3. modify/replace ics file on server (e.g. edit it from some other device/client 2 by adding another event b) - the ics file on the server contains event a and b. 4. delete the just added event a on client 1 (w/o updating the calendar before) 4a (client 1 downloads the ics file using get-method (client 1 ignores the results of the get-reuqest) and immediately puts the updated ics (based on client 1 local data) file to the server.) Actual Results: event b which was added on client 2 is lost - calendar on server is empty. Expected Results: Client 1 downloads the ics file, merges it with the requested change and uploads the merged file which contains all events, but not the event a which was requested for deletion.
From http://www.mozilla.org/projects/calendar/releases/lightning1.0b2.html#issues "Concurrent editing of remote calendars by multiple users can lose data."
This bug is still unconfirmed. So is this a permanent limitation, invalid bug, valid bug, ...?
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #3) > This bug is still unconfirmed. So is this a permanent limitation, invalid > bug, valid bug, ...?
Flags: needinfo?(bv1578) → needinfo?(makemyday)
This is a limitation by design - control of ics calendars changes are on file level (regardless whether it's the file is located on a web or a file server). If you want a more fine graned control on item level including a conflict handling, you use a caldav server, which is designed for that very purpose. The use case for an ICS calendars is typically a pusblished calendar, which is only controlled by a single maintainer.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.