Closed Bug 787780 Opened 13 years ago Closed 13 years ago

Add Support for current-user-principal / "group calendar" synchronization fails

Categories

(Calendar :: Provider: CalDAV, defect)

Lightning 1.7
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fs-email, Assigned: Fallen)

Details

(Whiteboard: [CalDAV server: eGroupware])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: After updating from TB14 to TB15 and from Lighting 1.6 to 1.7, one of the networked calendars in Lightning is no longer displayed. We use egroupware at the place where I work and we each have a personal calendar on the network as well as one "group calendar" which mirrors all the calendar events of the individual user calendars. Note that this group calendar is "read only" and that "cache" is off for all calendars. After the update, the group calendar stopped working. There could be a problem with parsing its URL - at least that is currently my hunch (note that I'm definitely not an expert) after realizing that my personal user calendar continues to work fine and after having tried to interpret the output of the error console. this is the path to my personal calendar on the network: https://gwsrv.WHERE.I.WORK/groupdav.php/calendar/ the group calendar's address, however, reads like this... https://gwsrv.WHERE.I.WORK/groupdav.php/GROUPNAME/calendar/ ... and that might, maybe, cause the problem? Actual results: please note that this is what the error console displays: Timestamp: 02.09.2012 12:37:26 Warning: Use of Mutation Events is deprecated. Use MutationObserver instead. Source File: chrome://calendar/content/widgets/calendar-widgets.xml Line: 306 Timestamp: 02.09.2012 12:37:28 Warning: Use of getAttributeNodeNS() is deprecated. Use getAttributeNS() instead. Source File: resource://calendar/modules/calXMLUtils.jsm Line: 32 Timestamp: 02.09.2012 12:37:28 Warning: Use of attributes' ownerDocument attribute is deprecated. Source File: resource://calendar/modules/calXMLUtils.jsm Line: 32 Timestamp: 02.09.2012 12:37:28 Warning: Use of getAttributeNodeNS() is deprecated. Use getAttributeNS() instead. Source File: resource://calendar/modules/calXMLUtils.jsm Line: 32 Timestamp: 02.09.2012 12:37:28 Warning: Use of attributes' ownerDocument attribute is deprecated. Source File: resource://calendar/modules/calXMLUtils.jsm Line: 32 Expected results: What should have happened is, of course, that after updating TB and Lightning *both* my calendars for professional use keep working. I hope this can be fixed because it is work related (and thus more urgent).
OS: All → Windows XP
Hardware: All → x86
You could enable the advanced preferences "calendar.debug.log" and "calendar.debug.log.verbose" and check the debug messages from CalDAV provider in Error Console. Maybe they report more information like URL problem or something else.
Good idea, thanks. The problem seems to be connected to finding <ns2:schedule-inbox-URL/> and <ns2:schedule-outbox-URL/>. These are all the bits of relevant information from the verbose debug output: CalDAV: Status 207 on initial PROPFIND for calendar "group calendar" CalDAV: Authentication scheme for "group calendar" is Basic CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:ns2="urn:ietf:params:xml:ns:caldav" xmlns:ns3="http://calendarserver.org/ns/"> <D:href>/groupdav.php/GROUPNAME/calendar/</D:href> <D:propstat> <D:prop> <D:owner><D:href>/groupdav.php/principals/groups/GROUPNAME/</D:href></D:owner> <D:resourcetype xmlns:ns4="http://groupdav.org/"><ns4:vevent-collection /><ns2:calendar /><D:collection /></D:resourcetype> <ns2:supported-calendar-component-set xmlns:ns2="urn:ietf:params:xml:ns:caldav"><ns2:comp name="VCALENDAR"/><ns2:comp name="VEVENT"/></ns2:supported-calendar-component-set> <D:supported-report-set><D:supported-report><D:report><ns2:calendar-query /></D:report><D:report><ns2:calendar-multiget /></D:report><D:report><ns2:free-busy-query /></D:report></D:supported-report></D:supported-report-set> <ns3:getctag>1346512620</ns3:getctag> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> CalDAV: initial ctag 1346512620 for calendar "group calendar" Adding supported items: VEVENT for calendar: "group calendar" CalDAV: Found principal url /groupdav.php/principals/groups/GROUPNAME/ CalDAV: send: OPTIONS https://gwsrv.WHERE.I.WORK/groupdav.php/GROUPNAME/ CalDAV: send: PROPFIND https://gwsrv.WHERE.I.WORK/groupdav.php/principals/groups/GROUPNAME/ <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><C:calendar-home-set/><C:calendar-user-address-set/><C:schedule-inbox-URL/><C:schedule-outbox-URL/></D:prop></D:propfind> CalDAV: recv: <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:"> <D:response xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:ns2="urn:ietf:params:xml:ns:caldav"> <D:href>/groupdav.php/principals/groups/GROUPNAME/</D:href> <D:propstat> <D:prop> <ns2:calendar-home-set><D:href>/groupdav.php/GROUPNAME/</D:href></ns2:calendar-home-set> <ns2:calendar-user-address-set><D:href>urn:uuid:accounts--25016-41d3f167a576cb09fa81fdaaa2cc146d</D:href><D:href>/groupdav.php/principals/groups/GROUPNAME/</D:href></ns2:calendar-user-address-set> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> <D:propstat> <D:prop> <ns2:schedule-inbox-URL/> <ns2:schedule-outbox-URL/> </D:prop> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat> </D:response> </D:multistatus>
same here: the user calendar works -> schedule-in an outbox are present. group calendar with "CalDAV calendar-user-type GROUP" does NOT reference the schedule-in/outbox-URLs, maybe because it does not make sense on group-cals? IΒ΄m very new on caldav - but I think this in CALDAV RFC under 2.2.1. CALDAV:schedule-inbox-URL Property: Description: This property allows a client to determine where the scheduling Inbox collection of the current user is located so that processing of scheduling messages can occur. If not present, then the associated calendar user is not enabled for reception of scheduling messages on the server. does not mean, that the presence of schedule-in/outbox-URLs is a MUST. so maybe this one can be solved in first checking if the calendar-user-type is GROUP and then not requesting the schedule-boxes-URLs? thx, abdul
ok, maybe the above was not the reason. I commented out these lines in calDavCalendar.js starting at line 1644: // check if owner is specified; might save some work // let owner = caldavXPathFirst(multistatus, "/D:multistatus/D:response/D:propstat/D:prop/D:owner/D:href/text()"); // if (owner) { // thisCalendar.mPrincipalUrl = owner; // cal.LOG("CalDAV: Found principal url " + thisCalendar.mPrincipalUrl); // } and now it works again with the group-calendar (at least with the group-calendar-url under my user-dir https://myserver.org/egroupware/groupdav.php/MyUsername/calendar-MyGroupname/ ) maybe itΒ΄s because egroupware caldav-server sends DAV owner on the principal page of the group.
Whiteboard: [CalDAV server: eGroupware][calconnect25]
Attached patch Fix - v1 β€” β€” Splinter Review
Reporter, could you check if this patch fixes your issue?
Assignee: nobody → philipp
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #666545 - Flags: review?(matthew.mecca)
Attachment #666545 - Flags: feedback?(abdul)
Whiteboard: [CalDAV server: eGroupware][calconnect25] → [CalDAV server: eGroupware]
Gladly. But I'm afraid I'll need a couple of brief instructions on how to apply the patch. Thanks, FS
1. Unpack lightning.xpi 2. go to components/calDavCalendar.js 3a. either manually apply that patch by removing all lines with a - at the beginning and adding in all lines with a + at the beginning (without the + of course). 3b. you can also use the "patch" utility, something like patch -p4 -i attachment.diff in the components/ directory. 4. repack lightning.xpi 5. install it and test
Done. It works. There are no more error messages on console. And both calendars now behave as they should, i.e. as they did before the update. Thanks. This is much appreciated.
confirmed - works!! great, thank you very much.
Comment on attachment 666545 [details] [diff] [review] Fix - v1 Untested, but looks good codewise. r=mmecca
Attachment #666545 - Flags: review?(matthew.mecca) → review+
Attachment #666545 - Flags: feedback?(abdul) → feedback+
On group calendars, DAV:owner is not the current-user's principal. We used to shortcut this because we feared not everyone might support cu-principal, but at least from calconnect, this is supported by every sever.
Summary: egroupware "group calendar" (CalDAV) synchronization fails → Add Support for current-user-principal / "group calendar" synchronization fails
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0
Target Milestone: 2.0 → 1.9
Target Milestone: 1.9 → 1.8
Attachment #666545 - Flags: approval-calendar-beta+
Attachment #666545 - Flags: approval-calendar-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: