Autopublishing of calendars on webdav server is not working.



16 years ago
12 years ago


(Reporter: rob, Assigned: mostafah)





16 years ago
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

16 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.


Comment 2

16 years ago
Confirming based on comment #1.
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

15 years ago
New contact from to
Filter on string OttawaMBA to get rid of these messages. 
Sorry for the spam.
Assignee: mikep → mostafah

Comment 4

15 years ago
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

15 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
Background: I'm using free ical service

1. I created a Test calendar and associated it with my account, e.g.
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 page, e.g.<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

15 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

15 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

Comment 8

15 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...

Comment 9

15 years ago
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

15 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

15 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

15 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

15 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.

Comment 16

15 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.

Those who have selected remote calendars to be refreshed at startup might have
encountered this problem.

Comment 17

15 years ago
*** Bug 225877 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
This has been fixed now.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 19

15 years ago
*** Bug 216254 has been marked as a duplicate of this bug. ***

Comment 20

15 years ago
*** Bug 207202 has been marked as a duplicate of this bug. ***
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.