Closed Bug 418050 Opened 16 years ago Closed 16 years ago

CalDAV events: Not displayed after program start until after creation of a new event [SOGo server]

Categories

(Calendar :: Provider: CalDAV, defect)

Product:
Calendar
Component:
Provider: CalDAV
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: siedler.edv, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080208 Fedora/2.0.0.12-1.fc7 Firefox/2.0.0.12
Build Identifier: Lightning 0.8pre (build 2008021618)

When starting Thunderbird/Lightning, none of my CalDav calendar events (own as well as foreign calendars) is displayed.

I am able to create an event in (my own) CalDav calendar, though. After doing so, the entire calendar is displayed again in Lightning.
The subscribed CalDAV calendars from my colleagues are still not displayed, however. I can'r create an event in there as I have only viewing access.


Reproducible: Always

Steps to Reproduce:
1. Created CalDAV calendars (server SW: SOGo) with earlier Lightning
2. Updated Lightning to newer nightly built
3. Restart Lightning - calendars are missing
4. Create new event - a short time later, the entire calendar (incl. new event) is displayed again


Expected Results:  
Calendar events for all CalDAV calendars should be displayed after program start.

Lightning 0.8pre as of Feb. 12, 2008, still worked.
From Feb. 13 onward the failure occurred.

Thunderbird version: 2.0.0.9
OS: Fedora 7
Keywords: regression
Version: unspecified → Mozilla 1.8 Branch
Can't reproduce the bug on Ubuntu 7.10.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8pre) Gecko/20071022 Lightning/0.8pre (2008021518) Thunderbird/2.0.0.6 ID:2007102215
Keywords: regression
Version: Mozilla 1.8 Branch → unspecified
WFM when upgrading from Lightning 2008021121 to v. 2008021700 (Windows)
@ Omar:
Is this a public calendar?
I tried to subscribe, but of course I have neither user name nor password...
Unfortunately, nothing changes after upgrading to Lightning 2008021700...

If that helps, the Thunderbird version is given as "Thunderbird 2.0.0.9 (X11/20071115)".

Another observation:
In order to make the CalDAV calendar events visible, I added another event. Behaviour remains unchanged from my first description.
However, panel "Find Events" (Unifinder?) is set to "All future events", but it nevertheless shows all past and future events?!
This is not just a one-time observation. Server software, Thunderbird version remained identical, the only change was the Lightning version.

If I go back to the nightly build of Feb. 12., CalDAV calendar display works, I updating to a newer version - it fails as described.
I have been trying this with multiple builds since then, but always reverted to build 20080212.
Afraid I don't have a SOGo calendar to test against. Do you see anything in the error console?
OS: Fedora core 7 (2.6.23.15-80.fc7)

Web Browser:Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20071128 
Fedora/2.0.0.10-2.fc7 Firefox/2.0.0.10

Email program: Thunderbird version: 2.0.0.9 (20071115)

Lightning Build Identifier: Lightning 0.8pre (build 2008021718)

Test Result:
1.After upgraded Lightning to 0.8pre (build 2008021718), nothing is displayed.
2.Unlike comment#5 adding another event won't display anything niether in the "Find event" panel.

I use Windows XP 2002 SP2

Mozilla Thunderbird version 2.0.0.9 (20071031)  with Lightning build 2008021718, 

and I have the same problem too.

When starting Thunderbird/Lightning, none of my CalDav calendar events (own as
well as foreign calendars) is displayed.

I am able to create an event in (my own) CalDav calendar, though. After doing
so, the entire calendar is displayed again in Lightning.

But, can't see the other CalDav Calendar.
It would be helpful if comments would specify what kind/version of CalDAV server is involved, not just the client. 
No problem:
CalDAV server is Scalable Open Groupware.org, version 1.0RC5.

Thanks. I was really aiming that last at the commenters in comments 8 and 9, who unlike you did not provide that information. I don't see this problem myself on five different CalDAV servers *not* including SOGo, and would like to find out if this is something specific to the MozCal/SOGo interaction.

@Bruno:
I am afraid, no eror messages in the Error Console.
Would it help to provide a SOGo account for testing?
Would it help to provide a SOGo account for testing?
For the record: Result don't change regardless whether I enabled or disabled the calendar caching feature.
This needs some investigation before release -> Setting blocking-calendar0.8?
Flags: blocking-calendar0.8?
Clarifications:
I am unsure whether (or to which extent) the server side affects this observation, particularly, because no SOGo changes happened during jumping between Lightning releases. But if somebody wishes to run any tests on this server - I can provide testing accounts.
Also, commenters Thaweeporn and Suphakit use the very same SOGo server - we are colleagues at work.

Is there anybody who uses Thunderbird 2.0.0.9 plus Lightning nightly builds after Feb 12, but doesn't see this behaviour?

Thanks for providing me with an account on your SOGo server. From what I can tell, what you are looking at is the result of a couple of different ways in which SOGo does not appear to fully support the CalDAV spec. 

New CalDAV code recently committed uses a multiget query on startup and refresh. Support for this query is defined as REQUIRED in para 7.9 of the spec, so it's reasonable to do so. SOGo apparently does not support it, so you do not see events on startup.

When you PUT an item to the server, the Mozilla CalDAV code immediately attempts to re-fetch it, since most CalDAV servers immediately modify such items and the client needs to keep track of such changes. The refetch is done with a query for items with the given UID. Near as I can tell, SOGo - incorrectly - returns all the items in the store on this query, which should return a single item; that's why you see all your items after a PUT. 

So ... it looks to me like this is a SOGo bug rather than a Mozilla one. I'm going to leave the bug open for a bit, though, in case someone else using a different server chimes in seeing something similar.

In response to the question in comment 19, I've had a couple of bug reports in the last week from people using current nightlies against CalDAV servers other than SOGo, and those people definitely did not see this problem. I don't see it, either (except on the SOGo account you kindly made me), with any of my development code.
mine CalDAV server is SoGo version 1.0RC5.
Keywords: qawanted
Summary: CalDAV events: Not displayed after program start until after creation of a new event → CalDAV events: Not displayed after program start until after creation of a new event [SOGo server]
Bruno is right. SOGo doesn't implement the complete CalDAV specification so it's perfectly normal that it fails on certain requests in Lightning that are not yet part of a release. We try to use Lightning as our primary CalDAV client for the moment. So any change in Lightning might break compatibility with SOGo.

Regarding the comment on the re-fetch after a PUT (3rd para above), I would have a comment.... I think you could simply test for changes in the "Location" field of the answer, and test the etag that may be returned. A server is not supposed to change the data of what it's being submitted, only the metadata.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-calendar0.8? → blocking-calendar0.8-
I wonder if the Open Groupware Server has this error too? Sogo is a fork of Ogo.
(In reply to comment #23)
> I wonder if the Open Groupware Server has this error too? Sogo is a fork of
> Ogo.
> 

I imagine that it does.I don't have regular access to an OGo server, but the last time I was able to check I saw, and reported, similar problems. I hate to see interop with OGo/SOGo break, but the recent changes to the CalDAV provider were IMO necessary, and the things we see breaking here (multiget and the query-by-uid) are both defined as "REQUIRED" in the CalDAV RFC. It would be really great if OGo/SOGo were to support them.

First: ScalableOGo is *not* a fork of the OGo server. I developed the original SOGo from scratch to target a different audience (SOGo is for plain iCal calendaring in very large deployments, OGo is more like a CRM system for small deployments).

Wolfgang (#22): the "Location" thing was discussed in a different bugreport. While I think that handling the location/etag is the more natural thing (and works with plain WebDAV servers!), SOGo and OGo should implement the mentioned UID report query.
I think one of the most important things is that SOGo returns a proper error code if it does not understand the report.

Bruno (#24): I think it is very unfortunate if Lightning completely drops support for plain WebDAV and require CalDAV. See, you can make Lightning work against plain Apache mod_dav if you provide good fallbacks (eg if the report is not supported, just reget by URL)! That would be just awesome! ;-)
IMHO a good approach would look like:
- handle the etag/location returned by the PUT (update location/etag in your cache)
- attempt to reget the resource using the UID and the CalDAV query
- if the server returns 500/501, attempt to reGET the resource using location + if-none-match:etag

Bas (#24): as mentioned OGo and ScalableOGo are very different from a technical point of view, this includes CalDAV handling (queries against the events/todos/etc are very different).
So even if Wolfgang adds the REPORT to SOGo, we would still need to add it to ZideStore (the OGo WebDAV frontend).
Before I look into the latter I'll probably wait for 0.8.


(In reply to comment #25) 
> Bruno (#24): I think it is very unfortunate if Lightning completely drops
> support for plain WebDAV and require CalDAV.

Helge, that is not the case. We still support plain ical files via HTTP, FTP and WebDAV and will so in the future. The user just has to condigure Lightning to use those. 

But when the user tells the app to work with a CalDAV server, then Lightning is expecting the server to support CalDAV spec.
(In reply to comment #26)
> Helge, that is not the case. We still support plain ical files via HTTP, FTP
> and WebDAV and will so in the future.

What I meant is not iCal-over-HTTP (full iCal calendar pushed over HTTP with a single GET/PUT), but plain WebDAV with one item per VEvent/etc. Aka GroupDAV ;-)
This allows a proper read/write WebDAV hosted calendar w/o any WebDAV extensions. I think thats quite an incentive to support that!
(you can even share a calendar r/w with the Outlook plugin I'm working on, just using mod_dav as a backend ;-)

> But when the user tells the app to work with a CalDAV server, then Lightning is
> expecting the server to support CalDAV spec.

As far as I can see supporting CalDAV *and* WebDAV should be very easy, its mostly about providing sensible fallbacks. WebDAV provides all operations to keep the local cache in sync, CalDAV is only really required to improve the efficiency of those (eg bulk resource fetch).

I understand that you want to focus on CalDAV, but I would like to suggest to _consider_ supporting plain WebDAV as well. Its not much work and has quite a big additional value (IMHO). No offense intended!
[but I won't push this to you guys any further, don't despair ;-)]

PS: if someone wants to discuss this further, I suggest moving to private mail instead of spamming the bugreport. Or meet me at FOSDEM! :-) (if you want to find me, ask at the GNUstep/OGo booth)

PS2: I suppose we can close this bug report. Its a 'bug' (mising CalDAV feature) in both, OGo and SOGo, and should be opened twice in the OGo Bugzilla.


Marking INVALID, as has been said, this is not our bug, but a bug in OGo and SOGo. Please file it in their bugzilla installation.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Flags: blocking-calendar0.8-
SOGo has support for multiget's too since 1.0rc5.3.
Thanks to everybody involved in the investigation!
You need to log in before you can comment on or make changes to this bug.