Last Comment Bug 787780 - Add Support for current-user-principal / "group calendar" synchronization fails
: Add Support for current-user-principal / "group calendar" synchronization fails
Status: RESOLVED FIXED
[CalDAV server: eGroupware]
:
Product: Calendar
Classification: Client Software
Component: Provider: CalDAV (show other bugs)
: Lightning 1.7
: x86 Windows XP
: -- normal (vote)
: 1.8
Assigned To: Philipp Kewisch [:Fallen]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-02 03:52 PDT by Frank Sauer
Modified: 2012-10-02 06:24 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Fix - v1 (1.49 KB, patch)
2012-10-01 07:33 PDT, Philipp Kewisch [:Fallen]
matthew.mecca: review+
philipp: feedback+
philipp: approval‑calendar‑aurora+
philipp: approval‑calendar‑beta+
Details | Diff | Review

Description Frank Sauer 2012-09-02 03:52:29 PDT
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).
Comment 1 Stefan Sitter 2012-09-03 11:11:03 PDT
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.
Comment 2 Frank Sauer 2012-09-04 00:54:25 PDT
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>
Comment 3 abdul 2012-09-25 15:10:35 PDT
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
Comment 4 abdul 2012-09-25 16:22:23 PDT
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.
Comment 5 Philipp Kewisch [:Fallen] 2012-10-01 07:33:25 PDT
Created attachment 666545 [details] [diff] [review]
Fix - v1

Reporter, could you check if this patch fixes your issue?
Comment 6 Frank Sauer 2012-10-01 07:53:32 PDT
Gladly. But I'm afraid I'll need a couple of brief instructions on how to apply the patch. Thanks, FS
Comment 7 Philipp Kewisch [:Fallen] 2012-10-01 08:58:30 PDT
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
Comment 8 Frank Sauer 2012-10-01 09:08:02 PDT
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 9 abdul 2012-10-01 12:15:11 PDT
confirmed - works!!

great, thank you very much.
Comment 10 Matthew Mecca [:mmecca] 2012-10-01 13:11:43 PDT
Comment on attachment 666545 [details] [diff] [review]
Fix - v1

Untested, but looks good codewise. r=mmecca
Comment 11 Philipp Kewisch [:Fallen] 2012-10-02 06:20:18 PDT
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.
Comment 12 Philipp Kewisch [:Fallen] 2012-10-02 06:21:27 PDT
Pushed to comm-central changeset 8f73db6a6144
Comment 13 Philipp Kewisch [:Fallen] 2012-10-02 06:21:44 PDT
Backported to releases/comm-aurora changeset f968ee7fe658
Comment 14 Philipp Kewisch [:Fallen] 2012-10-02 06:22:00 PDT
Backported to releases/comm-beta changeset b97e88007ad4

Note You need to log in before you can comment on or make changes to this bug.