Closed Bug 381573 Opened 19 years ago Closed 19 years ago

Sunbird 0.5pre & OpenGroupware nightly /w CalDAV not displaying new events

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: pav5088, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070521 Tested Sunbird 0.5pre & 0.3.1 with OpenGroupware nightly build 1953. Sunbird 0.3.1 works fine. Sunbird 0.5pre won't show events that are entered, but they show up later if the calendar display is refreshed (eg. in day view change to previous day, then back to current day). A Sunbird restart will also cause newly entered events to show up. To get anything showing up I needed to specify "dav" in the URL rather than "so" (ie. protocol autodetect didn't work). Reproducible: Always Steps to Reproduce: 1. Connect Sunbird to Opengroupware with URL ie. http://{host}/zidestore/dav/{username}/Calendar/ 2. Enter an event. This will not show up in either the event or calendar views. Actual Results: The entered event wasn't displayed in either the event or calendar views. If the event was the first one entered for the calendar a restart of Sunbird is required for the event to show up. If the event was not the first one entered into the calendar then a restart will still work, but also a refresh of the calendar view (eg. in day view, switching to another day, then switching back) will make the event show up in the calendar view but not in the event view. Expected Results: The event should show up immediately in the event and calendar views when entered. There are no errors listed in the error console.
I should also mention to any potential testers that there is a known issue (and fix) for Sunbird, OpenGroupware and timezones. See this email thread : http://www.nabble.com/ogo-calendar-on-ipod-t3025908.html
There is a zidestore.log file of chat between Sunbird and OpenGroupware/Zidestore at http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1874
Sunbird is at RC stage now, and I'm getting different (mis)behavior. OpenGroupware svn.1968 + Sunbird RC0.5 -- Events now appear right away, but now I have almost the inverse problem of the bug reported above - when the calendar view is refreshed by clicking to another day and back the event disappears. This problem only manifests when the calendar is empty on Sunbird startup - things are fine if the calendar contains events. I see an additional bug however - when a reminder for an event pops up a duplicate event is created. (The calendar must be refreshed for this to be displayed in Sunbird... but the duplicate event is saved back to OpenGroupware). I know I'm using a different nightly (OpenGroupware svn.1968 instead of svn 1950) but I believe Sunbird is the software which has changed - when I test with Sunbird 0.5PRE I get results consistant with bugs previously reported against Ogo svn.1950 in the bug report above.
When Sunbird PUTS a calendar resource to a calendaruri/ on on OpenGroupware, OGo places the resource in a different location than calendaruri/, causing both the problems reported here and those reported in bug 382219. Comment #1 in that bug is relevant.
Yes, bug 382219 is somewhat similiar. Though OGo actually returns a 'location' header pointing to the new location in the response to the PUT-create. It would be great if Sunbird would process that header and update its cache. I think I've reported another bug on this (processing of location) ~6...12 months ago. Anyways, 'location' in PUT responses seems to be a grey area for some. While I really dislike this I suppose we indeed need to change ZideStore to preserve the URL selected by a client during a PUT for best compat :-/ Meaning that this bug is on us ...
> Anyways, 'location' in PUT responses seems to be a grey area for some. While I > really dislike this I suppose we indeed need to change ZideStore to preserve > the URL selected by a client during a PUT for best compat :-/ > Meaning that this bug is on us ... > So Helge, can this bug be closed then?
The subject of the report should be renamed: Add support for PUT redirections using 'location' I still think that support for 'location' would be *very* nice and would make the live much easier for quite a few legacy server vendors. So I would prefer not closing the report completely. Summary: I suggest the severity of the report should be lowered from 'bug' to 'wishlist'.
(In reply to comment #7) In this case I suggest to file a new enhancement bug that has a clear report about the feature requested and close this bug.
Agreed. (can't close this bug myself, someone else need to do this. but I can then create the new bug with the technical details wrt location)
Closing (WONTFIX for want of a better choice) based on comment #9. This is not meant to imply anything about the forthcoming enhancement bug!
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.