Closed
Bug 200012
Opened 21 years ago
Closed 20 years ago
Autopublishing of calendars on webdav server is not working.
Categories
(Calendar :: General, defect)
Calendar
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rob, Assigned: mostafah)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030319 Debian/1.3-3 After adding an event/task to the calendar I have to manualy publish it to the webdav server. Have verified this in both windows and Linux build. Also does not automaticaly do a get before adding a new event. Reproducible: Always Steps to Reproduce: 1.Add an event 2.Watch apache access.log for a GET before hand and PUT afterward, nothing happens. 3.Open up the calendars tab 4.Highlight calendar 5.Right click and choose publish entire calendar. 6.Apache log shows PUT Actual Results: Described above Expected Results: step 2 should show a PUT in the apache access.log When an event is added the calendar should first perform a GET in order to be up to date and not overwrite I file this as a major bug, if people forget to publish their calendar and do a refresh the event disapears.
Comment 1•21 years ago
|
||
I Have observed the same with Linux and have been able to reproduce the behavior using Windows 2000: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Mozilla Calendar 2003033112-cal Oddly, for me with linux it appeared that immediately after setting up the remote calendars, the automatic refresh and publishing appeared to happen. Only later did the calendar cease automatically performing the refresh/updates. Odd. Joe.
Comment 2•21 years ago
|
||
Confirming based on comment #1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: clean-report
Hardware: PC → All
Summary: AUtopublishing of calendars on webdav server isnt working. → Autopublishing of calendars on webdav server is not working.
Comment 3•21 years ago
|
||
New contact from mikep@oeone.com to mostafah@oeone.com Filter on string OttawaMBA to get rid of these messages. Sorry for the spam.
Assignee: mikep → mostafah
confirming that auto publish does not publish added tasks autoamtically. one has to use the manual publish. Mozilla Calendar 2003080411-cal Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030720
Comment 5•21 years ago
|
||
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) Mozilla Calendar 2003061213-cal I'm also seeing a similar (related?) problem EVEN if I do NOT auto-publish the calendar!! Background: I'm using www.icalx.com free ical service 1. I created a Test calendar and associated it with my icalx.com account, e.g. webcal://www.icalx.com/private/<username>/Personal.ics 2. I then entered an event and manually published it which appeared to work OK. 3. I can see the event is published by visiting the icalx.com page, e.g. http://www.icalx.com/html/<username>/day.php?cal=Personal 4. I deleted the event with Mozilla calendar and then selected the 'Test' calendar and did a right-click 'Publish Entier Calendar' 5. The event does NOT get published. 6. If I then do Refresh Remote Calendar and it then brings back the event from the remote calendar that I just deleted! NOTE: The same thing happens if I do a local update of the event, then publish. Also, the same problem occurs if I use an http: URL rather than the webcal: URL. P.S. Is it possible that this is some kind of time synchronization problem between the local Mozilla client machine and the WebDAV (ical) server machine? I notice that iCalendar events have a DTSTAMP - could this be part of the sync mechanism that fails if the client/server clocks are out of sync (or do not both use the same timezone for time) ?
Comment 6•21 years ago
|
||
Regarding comment #5. I had to turn off caching (set cache size to 0) in order to get anything to work. Otherwise it just kept using the cached calendar, even when I told it to reload the remote one. You might try doing the same and see if you get better results.
Comment 7•21 years ago
|
||
Re: Comment #6 Thanks... I was having a problem with the cache as well. Is there some way to tell the Calendar to not use the cache without affecting Mozilla/Firebird?
Comment 8•21 years ago
|
||
Mozilla Calendar 2003092613-cal Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 The remote publishing fields: Location, Username, Password, and the "Publish Changes Automatically" settings are not saved for the calendar. I can only get calendar to publish on the "Default Remote Calendar" option. I'm not having any problems with cache....I think...though...not sure. I can only publish with "Publish Entire Calendar"...if this is the only way..fine...
After a bit of investigation, this is what seems to be happening: If you click on 'refresh remote calendars' it will only refresh the last calendar in your list of calendars. The only way to refresh a calendar is to book an appointment into the calendar you want to refresh (at which point it does a get, then a put). If you add a task, it doesn't write to the remote calendar at all. Publishing manually works fine (although it doesn't do a get first) If you do a manual publish, the auto-publish option is de-selected. When opening the calendar, it doesn't refresh the calendars (although this could be by design)
Comment 10•21 years ago
|
||
I am having the same Problems. "Publishing manually works fine (although it doesn't do a get first)" For me this seems to be a really big Problem for a shared calendar if I Select publish on a calendar which is not up to date I delete all the content of the up to date calendar.
Comment 11•21 years ago
|
||
Confirming that the option to automatically publish a remote calendar upon changes is de-selected when manually publishing once. This is highly annoying as I have to publish manually or tasks will be lost.
Comment 12•21 years ago
|
||
The main problem seems to be the cache. When I turn off the memory cache everything works fine. But it is not a solution to turn off the cache for the browser. In my opnion the calendar should always bypass the cache. This should be an easy thing to do for the developers.
Comment 13•21 years ago
|
||
I have only 1 calendar and it is remote via webDAV. It is currently setup for remote publication. I have seen various things that other have posted but I will try to add some more insight. I can't reproduce it reliably but I was able to have a remote file on the server that would not be updated locally when I asked for a refresh. This is my only calendar at this time so I have to disagree that "Refresh Remote Calendars" only refreshes the last calendar (see Additional Comment #9). That comment may be true also, but mine is the last and doesn't always work. Here is what else I found. 1. I made a change to an event and let it autopublish and it did so correctly (verified by looking at the file on the server). 2. I verified that my local file was also correct. 3. I asked it to refresh my local calendar at which point it replaced my local file with an older version without the change. This file was most likely cached by someone along the line (like others have said). 4. I browse the remote calendar file directly through the HTTP server. It shows up correctly so it is not the web server cache. 5. Refresh the local calendar again. It still doesn't get the correct one from the server. 6. Shutdown Mozilla and Calendar to purge the memory cache. 7. Restart Mozilla and Calendar and try to refresh. Still using an old copy so it must be in file cache somewhere. 8. Delete the calendar from Mozilla/Calendar which you think might purge some file cache. Verify the local copy is gone from the calendar directory. 9. Resubscribe to the calendar. You think, maybe as a new calendar (however, using the same remote file) that it might override the cache. Nope, still using the old copy. That copy must come from the Mozilla file cache. 10. Wait a day. 11. Refresh and get the correct new copy (file cache must have expired). So what have I added to this discussion. Only that in my case, the webDAV publishing *does* work correctly when I add a *single* new event or edit a *single* exisiting event after some time has passed since your last edit. The last part is key. The problem appears to be in the file cache (like others have said). The calendar does not correctly get a current copy of the remote calendar either when you refresh the calendar *or* before you add a new event or edit an exisiting event unless some time has passed which apparently purges the file cache. This failure to get a current copy is why events disapprear because the correct local copy gets overwritten with an out-of-date "remote" copy that comes from cache rather then the server (just my summary). In addition, when you make a change to a *recent* GET of the calendar, the local copy does get changed but it doesn't PUT it (like others have said) to the server. But it does ... sometimes!? An autopublish *didwork* for a single event when some time has passed since the last PUT. Almost like the cache is smart about GET *and* PUT events (which I didn't expect it to be). Manually running "Publish Entire Calendar" does appear to override the PUT cache (or there is no such thing, I am an idiot, and autopublish works more sparadically that I thought). Either way, you are screwed because when you try to add or change another event, your calendar will be replaced with an out-of-date copy that most likely doesn't contain your last edit. Solution: Play with the cache settings like other have suggested or make only one calendar change per day. :) We need to force GET and PUT commands through the file cache which should not be too hard since a user can force it from the browser if they want (Shift+Reload) and "Publish Entire Calendar" seems to work every time. Sorry for the length of this rehash but I had a few points that needed to be injected into lots of comments here and there.
Assignee | ||
Comment 14•21 years ago
|
||
This checkin will make sure the cache is bypassed when reloading a remote calendar: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=calendarManager.js&branch=&root=/cvsroot&subdir=mozilla/calendar/resources/content&command=DIFF_FRAMESET&rev1=1.61&rev2=1.62
Assignee | ||
Comment 15•21 years ago
|
||
This checkin will make sure the auto-publish option is not deselected if an entire calendar is published manually: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=calendar.js&branch=&root=/cvsroot&subdir=mozilla/calendar/resources/content&command=DIFF_FRAMESET&rev1=1.114&rev2=1.115
Assignee | ||
Comment 16•21 years ago
|
||
This checkin will make sure remote calendars are refreshed in turn instead of simultaneously which may cause problems with authenticating on the same server. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=calendarManager.js&branch=&root=/cvsroot&subdir=mozilla/calendar/resources/content&command=DIFF_FRAMESET&rev1=1.62&rev2=1.63 Those who have selected remote calendars to be refreshed at startup might have encountered this problem.
Assignee | ||
Comment 17•20 years ago
|
||
*** Bug 225877 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•20 years ago
|
||
This has been fixed now.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 19•20 years ago
|
||
*** Bug 216254 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 20•20 years ago
|
||
*** Bug 207202 has been marked as a duplicate of this bug. ***
Comment 21•18 years ago
|
||
The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!
QA Contact: gurganbl → general
You need to log in
before you can comment on or make changes to this bug.
Description
•