Closed
Bug 519225
Opened 15 years ago
Closed 14 years ago
Remotely shared calendar still shows events deleted by other calendar participants
Categories
(Calendar :: Provider: CalDAV, defect)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b2
People
(Reporter: m.duelli, Assigned: browning)
References
Details
Attachments
(3 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 We have a shared calendar on a Davical 0.9.7.3 CalDAV server. Every participant in the shared calendar has permission to add and remove events or task, respectively. Another participant created a new event with Gnome Evolution which I cannot delete with lightning. Also another participant created a new event with Apple iCal which I cannot delete with lightning either. (This is no regression, it already happend with TB 3.0b3 and older lightning nightlies, at least two month ago.) I have no problem to create events in this calendar and delete events that I created myself. I found that the URL that is used with Davical is different if an event is created with lightning. In short: Deletion of an event created with Evolution fails: CalDAV: Deleting https://server/caldav.php/shared-calendar/home/20090907T103150Z.ics Deletion of an event created with Lightning succeeds: CalDAV: Deleting https://server/caldav.php/shared-calendar/home/beba0c46-8790-4f75-8fd9-758cab1a49ef.ics Note the different encoding! I will attach some debug output! BTW in the last line of the debug output a space character is missing between calendar and Calendar, resulting in calendarCalendar. Reproducible: Always Steps to Reproduce: 1. Create a shared calendar, all participants have read and write access 2. Let someone else create an event/task 3. Try to delete this event with lightning Actual Results: An error message occurs: CalDAV: Deleting https://server/caldav.php/shared-calendar/home/20090907T103150Z.ics CalDAV: Unexpected status 404 deleting item from Calendar (shared). Content: Warnung: There has been an error reading data for calendar: Calendar (shared). However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_REMOVE_ERROR. Description: There was an error deleting the item from the server. Error: An error occurred when writing to the calendar Calendar (shared)! Error code: MODIFICATION_FAILED. Description: Source: file:///home/duelli/.thunderbird/9abcde5d.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calUtils.jsm -> file:///home/duelli/.thunderbird/9abcde5d.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js Line: 997 Expected Results: Correctly handle UIDs of different clients. It seems to be stored in the VEVENT
|
Reporter | |
Comment 1•15 years ago
|
||
|
||
Updated•15 years ago
|
Attachment #403257 -
Attachment mime type: application/octet-stream → text/plain
|
|
||
Comment 2•15 years ago
|
||
Could this be a permission issue? Can they delete your events? The debug log you attached says that the deletion succeeded. The different file name shouldn't be a problem.
|
|
Reporter | |
Comment 3•15 years ago
|
||
(In reply to comment #2) First of all: > The debug log you attached says that the deletion succeeded. The attached log is for an event I created myself. As I said, such events work fine (create+delete). The failed delete process is in the "Actual Result" section. (Sorry, for potential confusion). > Could this be a permission issue? Can they delete your events? All participants have the "assistant" permission for this calendar which is the highest permission in DAViCAL. It seems to work since all participants are allowed to write to the calender. However, I will check if the other participants are only allowed to create events. > The different file name shouldn't be a problem. Also not sure about this.
|
|
Reporter | |
Comment 4•15 years ago
|
||
Sorry for the confusion. We found that it is not a permission problem on the CalDAV Server. It is a problem with lightning's caching functionality of remote calendars (which is still marked experimental!) at least via CalDAV. It showed events (no matter whether created by myself or others) that were delete by others! Neither automatic nor manual update of the remote calendar correctly updated the cache. As soon as I deactivated cache for this calendar, the deleted items disappeared. P.S.: I could not find another bug related to caching in calendar component, so I will just change the title of this bug for now.
|
|
Reporter | |
Updated•15 years ago
|
Summary: Cannot remove event/task in shared CalDAV calendar which was created with another client → Remotely shared calendar still shows events deleted by other calendar participants when CACHE is active
|
|
||
Comment 5•15 years ago
|
||
Strange, I haven't noticed this with other caldav servers. I'd need access to a such server to create a patch. Not sure I'll have time to do this right now though. Another thing you could try: 1. make sure your calendar is synchronized to the remote one 2. let other user delete event 3. clear error console 4. synchronize again 5. attach log here Maybe davical is showing the deleted events in a wrong way? We haven't really changed anything in the caching code for a while. Can you try this with a different caldav server?
|
|
Reporter | |
Comment 6•15 years ago
|
||
(In reply to comment #5) > Another thing you could try: > > 1. make sure your calendar is synchronized to the remote one > 2. let other user delete event > 3. clear error console > 4. synchronize again > 5. attach log here I did the steps as you recommended: 0. Create a test event in a shared calendar 1. Reload remote calendars 2. Other user saw and deleted my test event 3. cleared error console 4. Reload remote calendars The interesting thing is that the same error appears although CACHE is not active for this calendar, so the topic of this bug should be changed... again! See the attached log file.
Attachment #403257 -
Attachment is obsolete: true
|
|
||
Comment 7•15 years ago
|
||
Unfortunately, I can't see anything from the debug log. I guess this needs a debugger and access to find out why its failing.
|
||
Comment 8•15 years ago
|
||
I can confirm this bug is still present with sunbird 1.0b1 ( even with two sunbird session working on the same shared calendar ) To have access to a full testing/debugging live serveur take a look at http://caldav-test.ioda.net ( a page explaining how to use it would be shown ) I will attach the log of cli2 (which have the deleted event always present until you close and reopen sunbird) Before the b1 ( sunbird pre-1.0 when cli2 try to modify deleted even calendar there was an error and the calendar was tagged as faulty, now this doesn't appear. ) cli2 was able to modify a deleted events re-save it, but if close & reopen sunbird, the event doesn't exist.
|
|
||
Comment 9•15 years ago
|
||
The full debug of sunbird session where the event should not be there. on cli1 we receive correct confirmation of deletion, and the event goes away. Notice : the event can be deleted by cli2, and then it will remain in cli1 until you restart sunbird.
|
|
||
Comment 10•15 years ago
|
||
You can modify the subject, this append also without cache active
|
|
Reporter | |
Comment 11•15 years ago
|
||
(In reply to comment #10) > You can modify the subject, this append also without cache active You are right, I already
Summary: Remotely shared calendar still shows events deleted by other calendar participants when CACHE is active → Remotely shared calendar still shows events deleted by other calendar participants
|
|
Reporter | |
Comment 12•15 years ago
|
||
(In reply to comment #11) > (In reply to comment #10) > > You can modify the subject, this append also without cache active You are right, I already noticed this in comment #6. I updated the subject. (Sorry, last comment was incomplete due to update of the subject :-)
|
||
Comment 13•15 years ago
|
||
I suspect that DAViCal is not responding with a different getctag response after the delete. Lightning (and iCal) both depend on this, and I think Evolution does in recent versions too. The getctag in DAViCal is assigned by a database trigger, so you need to make sure the triggers are up-to-date by running update-davical-database. Cheers, Andrew.
|
|
Reporter | |
Comment 14•15 years ago
|
||
(In reply to comment #13) > I suspect that DAViCal is not responding with a different getctag response > after the delete. Lightning (and iCal) both depend on this, and I think > Evolution does in recent versions too. > > The getctag in DAViCal is assigned by a database trigger, so you need to make > sure the triggers are up-to-date by running update-davical-database. > > Cheers, > Andrew. We have always used the update script for the PostgreSQL database after each update. So could this be the issue here?
|
|
||
Comment 15•15 years ago
|
||
It could still be that something went wrong with the update script. You can see whether the trigger is working properly by doing the following SQL before and after the delete: SELECT getetag FROM collection WHERE dav_name = '/username/home/'; Assuming a collection path of .../caldav.php/username/home/. If the value has changed, but Mozilla does not see the changes then it probably is a Mozilla issue. If the value has not changed then it is definitely a DAViCal issue.
|
|
||
Comment 16•15 years ago
|
||
Hi all, after be sure that davical is up to date. ./update-davical-database --debug --dbname "caldav-test" --dbuser root --appuser "davical_app" --owner "davical_dba" Using database: root%@dbi:Pg:dbname=caldav-test The database is version 8.1 currently at revision 1.2.5. Looking at patches[0] (1.1.2.sql) Patch 1.1.2.sql has already been applied. Looking at patches[1] (1.1.3.sql) Patch 1.1.3.sql has already been applied. Looking at patches[2] (1.1.4.sql) Patch 1.1.4.sql has already been applied. Looking at patches[3] (1.1.5.sql) Patch 1.1.5.sql has already been applied. Looking at patches[4] (1.1.6.sql) Patch 1.1.6.sql has already been applied. Looking at patches[5] (1.1.7.sql) Patch 1.1.7.sql has already been applied. Looking at patches[6] (1.1.8.sql) Patch 1.1.8.sql has already been applied. Looking at patches[7] (1.1.9.sql) Patch 1.1.9.sql has already been applied. Looking at patches[8] (1.1.10.sql) Patch 1.1.10.sql has already been applied. Looking at patches[9] (1.1.11.sql) Patch 1.1.11.sql has already been applied. Looking at patches[10] (1.1.11a.sql) Patch 1.1.11a.sql has already been applied. Looking at patches[11] (1.1.12.sql) Patch 1.1.12.sql has already been applied. Looking at patches[12] (1.1.12a.sql) Patch 1.1.12a.sql has already been applied. Looking at patches[13] (1.2.1.sql) Patch 1.2.1.sql has already been applied. Looking at patches[14] (1.2.1a.sql) Patch 1.2.1a.sql has already been applied. Looking at patches[15] (1.2.1b.sql) Patch 1.2.1b.sql has already been applied. Looking at patches[16] (1.2.2.sql) Patch 1.2.2.sql has already been applied. Looking at patches[17] (1.2.3.sql) Patch 1.2.3.sql has already been applied. Looking at patches[18] (1.2.3a.sql) Patch 1.2.3a.sql has already been applied. Looking at patches[19] (1.2.4.sql) Patch 1.2.4.sql has already been applied. Looking at patches[20] (1.2.5.sql) Patch 1.2.5.sql has already been applied. No patches were applied. Here the sql used to verfiy changes ( field getetag doesn't exist in collection here ?) SELECT dav_etag, dav_name,modified FROM collection WHERE dav_name = '/yellow/home/'; cli1 create an event "68bb7be1076a76929b4bcdbf8e650047";"/yellow/home/";"2009-12-07 08:23:10.759266+01" cli2 modify it "c5eb49ab55234cab7bd745e28599de97";"/yellow/home/";"2009-12-07 08:24:00.536973+01" cli1 delete it "918436afe820a33ce89b2d68b90a81f6";"/yellow/home/";"2009-12-07 08:24:48.124153+01" cli2 never update it's view , only after a restart so seems to be a sunbird bug.
|
|
||
Comment 17•15 years ago
|
||
The sunbird debug log on cli2 during the 3 operations CalDAV: send(http://caldav-test.ioda.net/caldav.php/yellow/home/): <?xml version="1.0" encoding="UTF-8"?> <calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> <calendar-data/> </D:prop> <D:href>/caldav.php/yellow/home/d5df784a-6d56-47b0-8248-8bd45c437f43.ics</D:href> </calendar-multiget> CalDAV: Status 207 fetching calendar-data for calendar Yellow CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <response> <href>/caldav.php/yellow/home/d5df784a-6d56-47b0-8248-8bd45c437f43.ics</href> <propstat> <prop> <getetag>"e7bd9d95e5a684aaa2a74f5304d3e444"</getetag> <C:calendar-data>BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Zurich X-LIC-LOCATION:Europe/Zurich BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20091207T072256Z LAST-MODIFIED:20091207T072307Z DTSTAMP:20091207T072307Z UID:d5df784a-6d56-47b0-8248-8bd45c437f43 SUMMARY:cli1 create event DTSTART;TZID=Europe/Zurich:20091207T120000 DTEND;TZID=Europe/Zurich:20091207T130000 END:VEVENT END:VCALENDAR </C:calendar-data> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: refresh completed with status 207 at http://caldav-test.ioda.net/caldav.php/yellow/home/ CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Zurich X-LIC-LOCATION:Europe/Zurich BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20091207T072256Z LAST-MODIFIED:20091207T072357Z DTSTAMP:20091207T072357Z UID:d5df784a-6d56-47b0-8248-8bd45c437f43 SUMMARY:cli1 create event / cli2 modify it DTSTART;TZID=Europe/Zurich:20091207T120000 DTEND;TZID=Europe/Zurich:20091207T130000 X-MOZ-GENERATION:1 END:VEVENT END:VCALENDAR CalDAV: Item modified successfully on Yellow CalDAV: send(http://caldav-test.ioda.net/caldav.php/yellow/home/: <calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> <calendar-data/> </D:prop> <D:href>/caldav.php/yellow/home/d5df784a-6d56-47b0-8248-8bd45c437f43.ics</D:href> </calendar-multiget> CalDAV: send(http://caldav-test.ioda.net/caldav.php/yellow/home/): <?xml version="1.0" encoding="UTF-8"?> <calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> <calendar-data/> </D:prop> <D:href>/caldav.php/yellow/home/d5df784a-6d56-47b0-8248-8bd45c437f43.ics</D:href> </calendar-multiget> CalDAV: Status 207 fetching calendar-data for calendar Yellow CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> <response> <href>/caldav.php/yellow/home/d5df784a-6d56-47b0-8248-8bd45c437f43.ics</href> <propstat> <prop> <getetag>"7cf9293e9aa343fb6d5cd440226e74a0"</getetag> <C:calendar-data>BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Zurich X-LIC-LOCATION:Europe/Zurich BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20091207T072256Z LAST-MODIFIED:20091207T072357Z DTSTAMP:20091207T072357Z UID:d5df784a-6d56-47b0-8248-8bd45c437f43 SUMMARY:cli1 create event / cli2 modify it DTSTART;TZID=Europe/Zurich:20091207T120000 DTEND;TZID=Europe/Zurich:20091207T130000 X-MOZ-GENERATION:1 END:VEVENT END:VCALENDAR </C:calendar-data> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: refresh completed with status 207 at http://caldav-test.ioda.net/caldav.php/yellow/home/ CalDAV: send(http://caldav-test.ioda.net/caldav.php/yellow/home/): <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/"> <D:prop> <CS:getctag/> </D:prop> </D:propfind> CalDAV: Status 207 checking ctag for calendar Yellow CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:" xmlns:A="http://calendarserver.org/ns/"> <response> <href>/caldav.php/yellow/home/</href> <propstat> <prop> <A:getctag>"918436afe820a33ce89b2d68b90a81f6"</A:getctag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: send(http://caldav-test.ioda.net/caldav.php/yellow/home/): <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop> <D:getcontenttype/> <D:getetag/> </D:prop> </D:propfind> CalDAV: ctag mismatch on refresh, fetching data for calendar Yellow CalDAV: recv: <multistatus> <response> <href>/caldav.php/yellow/home/</href> <propstat> <prop> <getcontenttype>httpd/unix-directory</getcontenttype> <getetag>"918436afe820a33ce89b2d68b90a81f6"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/01ab86f8-6a9c-4a2d-a312-c1b448ba5f5d.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"3b9a69aee459d708135b09aee8b6352c"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/3e35e98e-470e-4c3d-abca-5ccdd0e3d125.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"76583b88996be1f4163067da4b61680a"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/869ccac5-7062-43df-a284-400c54a38f80.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"c251bbaafa2b489d018e0d9968f3ca16"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/8b70c3fb-845c-4588-85fb-13b19804d27a.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"e83b80ae16affc4ab1bafe39d713b4a1"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/9a1ef9aa-bd0e-4937-9f38-117919c72087.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"8e35906144fe19cec31551e5d7fd06b9"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/d8b6a399-5899-4000-800d-a84df2b8cdb0.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"94135ec3351fed604c6f7e786e017e71"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> <response> <href>/caldav.php/yellow/home/e8b772c6-e5dc-4313-ad30-6442d406ae98.ics</href> <propstat> <prop> <getcontenttype>text/calendar</getcontenttype> <getetag>"d226fe34220321a8a8ae614005198910"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: send(http://caldav-test.ioda.net/caldav.php/yellow/home/): <D:propfind xmlns:D="DAV:" xmlns:CS="http://calendarserver.org/ns/"> <D:prop> <CS:getctag/> </D:prop> </D:propfind> CalDAV: Status 207 checking ctag for calendar Yellow CalDAV: recv: <?xml version="1.0" encoding="utf-8" ?> <multistatus xmlns="DAV:" xmlns:A="http://calendarserver.org/ns/"> <response> <href>/caldav.php/yellow/home/</href> <propstat> <prop> <A:getctag>"918436afe820a33ce89b2d68b90a81f6"</A:getctag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> CalDAV: ctag matches, no need to fetch data for calendar Yellow
|
|
||
Comment 18•15 years ago
|
||
OK, that certainly does seem to suggest the problem is in Mozilla, and yes the field in the table is dav_etag not getetag as I said above. It's clear that it has *seen* the A:getctag change, and then does a PROPFIND to find *what* has changed, but it would seem it is not removing the absent event from it's internal view. Convincing enough for me, anyway - marking as NEW Cheers, Andrew.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Updated•15 years ago
|
Flags: blocking-calendar1.0?
OS: Linux → All
Hardware: x86 → All
|
Assignee | |
Comment 19•15 years ago
|
||
I was able to reproduce the bug on my Bedework instance; this patch seems to fix the problem there and I'd like to see others test it as well. Looks like it works on the davical.org server too. FWIW I was unable to reproduce the bug on my own DAViCal server since that server never updates the ctag when I add/modify/remove items using Sunbird. That's an apt-gotten davical on Ubuntu 9.10 that's been around / gotten upgraded for a while. Possible that other davical-ubunteros will have the same problem, and thus that Andrew's suspicions wrt the ctag are correct in some cases.
|
|
||
Comment 20•15 years ago
|
||
Great, thanks Bruno. The database update script does not automatically get run when the DAViCal package is upgraded - it needs to get run manually. From version 0.9.8 it will complain visually in the admin UI if it isn't up to date, however.
|
|
||
Comment 21•15 years ago
|
||
Is there a way to try this path without the source ? just drive me where it is located in a sunbird-10 default install Thanks.
|
|
||
Comment 22•15 years ago
|
||
To find the file to change on my system, I: ~/$ cd ~/.thunderbird ~/.thunderbird$ find . -name calDavRequestHandlers.js There's only one additional line to paste. Cheers, Andrew.
|
|
||
Updated•15 years ago
|
Assignee: nobody → browning
Status: NEW → ASSIGNED
|
|
||
Comment 23•15 years ago
|
||
Thanks Andrew. don't understand why I was not find it by eyes :-) I've apply the patch, and made all sort of create/modify/delete with one or several events on one or several schedules. Success in all case. Thank you for the patch. When this is applied to official build, (note version here) Bruno can close the bug.
|
|
Assignee | |
Comment 24•15 years ago
|
||
Comment on attachment 416767 [details] [diff] [review] [short,test] after detecting server-side item deletion, remove it from local mTargetCalendar Requesting review. This patch simply re-adds a line that we had (in slightly different form but not in impact) in 0.9. It's not clear to me why it was removed in the patch for bug #469767.
Attachment #416767 -
Flags: review?(philipp)
|
|
||
Comment 25•15 years ago
|
||
Thanks Bruno. what the funny is the path made for accelerate sunbird.which make me smile. I've reported that in #530423 which is actual. So many progress have to be done before we can say hé look our product is so cool and efficient :-)
|
|
||
Updated•15 years ago
|
Attachment #416767 -
Attachment description: after detecting server-side item deletion, remove it from local mTargetCalendar → [short,test] after detecting server-side item deletion, remove it from local mTargetCalendar
|
|
||
Comment 26•15 years ago
|
||
For me it works, I've just been waiting for b2 in localized languages to deploy it . Is it already include in b2 english ?
|
|
Assignee | |
Comment 27•15 years ago
|
||
(In reply to comment #26) > Is it already include in b2 english ? The patch is still awaiting review, so it isn't included in any publicly-available builds.
|
|
||
Updated•14 years ago
|
Attachment #416767 -
Flags: review?(philipp) → review+
|
|
||
Comment 28•14 years ago
|
||
Comment on attachment 416767 [details] [diff] [review] [short,test] after detecting server-side item deletion, remove it from local mTargetCalendar >+ this.calendar.mTargetCalendar.deleteItem(foundItem, getItemListener); No need to pass in a listener, since we don't process foundItem anywhere afterwards. r=philipp with this fixed, I'll take care of the checkin in a moment.
|
|
||
Comment 29•14 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/98ab90c0d060> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: blocking-calendar1.0?
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
You need to log in
before you can comment on or make changes to this bug.
Description
•