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)
Tracking
(Not tracked)
RESOLVED
FIXED
1.8
People
(Reporter: fs-email, Assigned: Fallen)
Details
(Whiteboard: [CalDAV server: eGroupware])
Attachments
(1 file)
|
1.49 KB,
patch
|
mmecca
:
review+
Fallen
:
feedback+
Fallen
:
approval-calendar-aurora+
Fallen
:
approval-calendar-beta+
|
Details | Diff | Splinter Review |
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).
| Reporter | ||
Updated•13 years ago
|
OS: All → Windows XP
Hardware: All → x86
Comment 1•13 years ago
|
||
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.
| Reporter | ||
Comment 2•13 years ago
|
||
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.
| Assignee | ||
Updated•13 years ago
|
Whiteboard: [CalDAV server: eGroupware][calconnect25]
| Assignee | ||
Comment 5•13 years ago
|
||
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)
| Assignee | ||
Updated•13 years ago
|
Attachment #666545 -
Flags: feedback?(abdul)
| Assignee | ||
Updated•13 years ago
|
Whiteboard: [CalDAV server: eGroupware][calconnect25] → [CalDAV server: eGroupware]
| Reporter | ||
Comment 6•13 years ago
|
||
Gladly. But I'm afraid I'll need a couple of brief instructions on how to apply the patch. Thanks, FS
| Assignee | ||
Comment 7•13 years ago
|
||
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
| Reporter | ||
Comment 8•13 years ago
|
||
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.
Comment 10•13 years ago
|
||
Comment on attachment 666545 [details] [diff] [review]
Fix - v1
Untested, but looks good codewise. r=mmecca
Attachment #666545 -
Flags: review?(matthew.mecca) → review+
| Assignee | ||
Updated•13 years ago
|
Attachment #666545 -
Flags: feedback?(abdul) → feedback+
| Assignee | ||
Comment 11•13 years ago
|
||
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
| Assignee | ||
Comment 12•13 years ago
|
||
Pushed to comm-central changeset 8f73db6a6144
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0
| Assignee | ||
Comment 13•13 years ago
|
||
Backported to releases/comm-aurora changeset f968ee7fe658
Target Milestone: 2.0 → 1.9
| Assignee | ||
Comment 14•13 years ago
|
||
Backported to releases/comm-beta changeset b97e88007ad4
Target Milestone: 1.9 → 1.8
| Assignee | ||
Updated•13 years ago
|
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.
Description
•