search

medabdellahi / google-caldav-issues

Automatically exported from code.google.com/p/google-caldav-issues
0 stars 0 forks source link

Support calendar-home-set property on login principal #3

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. perform a PROPFIND depth:0 on the login principal (eg helge@gmail.com)

What is the expected output?

The DAV:response should contain a CalDAV calendar-home-set property
pointing to the calendar collections the logged in user is allowed to access.

Something like:
---snip---
<D:multistatus xmlns:D="DAV:"
              xmlns:C="urn:ietf:params:xml:ns:caldav">
 <D:response>
   <D:href>/calendar/dav/helge@gmail.com/user</D:href>
   <D:propstat>
     <D:status>HTTP/1.1 200 OK</D:status>
     <D:prop>
       <C:calendar-home-set>
         <D:href>/calendar/dav/helge@gmail.com/</D:href>
         <D:href>/calendar/dav/899812-29838@gmail.com/</D:href>
         <D:href>/calendar/dav/125332-27362@gmail.com/</D:href>
       </C:calendar-home-set>
     </D:prop>
   </D:propstat>
 </D:response>
</D:multistatus>
---snap---

What do you see instead?

Just the primary calendar set collection:
---snip---
<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/calendar/dav/helge@gmail.com/user</D:href>
    <D:propstat>
      <D:status>HTTP/1.1 200 OK</D:status>
      <D:prop>
        <C:calendar-home-set xmlns:C="urn:ietf:params:xml:ns:caldav">
          <D:href>/calendar/dav/helge@gmail.com/</D:href>
        </C:calendar-home-set>
      </D:prop>
    </D:propstat>
  </D:response>
</D:multistatus>
---snap---

Please provide any additional information below.

Notably the calendar-home-set points to a regular WebDAV collection which
then contains the actual calendar collections. This is already properly by
the Google CalDAV interface.

Original issue reported on code.google.com by helge.h...@googlemail.com on 31 Jul 2008 at 6:31

GoogleCodeExporter commented 9 years ago 
It's not calendars the logged-in user "is allowed to access"; RFC 4791 refers 
to collections that are "owned by" the user.

Original comment by ipqu...@googlemail.com on 15 Nov 2010 at 4:25

GoogleCodeExporter commented 9 years ago 
Yes. Ideally the secondary calendars should just show up in the primary root. 
This was meant as a workaround for that. If the former works, we can close this 
;-)

Original comment by helge.h...@googlemail.com on 15 Nov 2010 at 6:26

GoogleCodeExporter commented 9 years ago

Original comment by lu...@google.com on 21 Mar 2014 at 3:36