Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advertise WebCal calendar URLs (feature request) #776

Closed
belidzs opened this issue Jan 27, 2018 · 14 comments
Closed

Advertise WebCal calendar URLs (feature request) #776

belidzs opened this issue Jan 27, 2018 · 14 comments

Comments

@belidzs
Copy link

belidzs commented Jan 27, 2018

According to this a CalDav server can advertise Webcal calendars. These are typically used to access read-only, shared calendars.

DAVdroid recognizes Webcal calendars in the calendar home set which are published with resourcetype: subscribed and shows them in the DAVdroid account activity. If you select such a Webcal collection for synchronization, DAVdroid passes the URL to an installed Webcal-capable app like ICSdroid so that this app can subscribe to the calendar.

It would be nice if I could add these calendar URLs to my account so DAVdroid and other clients would display those extra calendars automagically.

@ialokim
Copy link

ialokim commented Jun 7, 2019

Would be really great to see this functionality added!

Some research (e.g. here) showed me the "advertisement" should at least contain the following xml:

 <d:response>
  <d:href>/<user>/<calendar-name>/</d:href>
  <d:propstat>
   <d:prop>
    <d:resourcetype>
     <d:collection/>
     <cs:subscribed/>
    </d:resourcetype>
    <cs:source>
     <d:href>http://www.somesite.com/public-calendar.ics</d:href>
    </cs:source>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
 </d:response>

So, instead of <c:calendar/>, it should contain <cs:subscribed/> and an <cs:source> tag for specifying the (public) ics file. (Where 'cs' would be the calendarserver namespace, e.g. xmlns:cs="http://calendarserver.org/ns/".)

@leso-kn
Copy link
Contributor

leso-kn commented Apr 24, 2020

The subscribed calendars could be stored inside a single .props file in the root of each collection (e.g. .subscriptions.props).

Like this each user could have their own subscriptions in a multi user instance - given that each collection refers to one user.

@leso-kn
Copy link
Contributor

leso-kn commented Nov 8, 2020

Any update on this? @Kozea

@dorchain
Copy link

I second the request.

@MrPixelized
Copy link

I, too, second the request.

@miklcct
Copy link

miklcct commented Oct 18, 2021

Any update on this?

@maartenweyns
Copy link

Came here to leave a comment, this feature would be highly appreciated!

@tunbridgep
Copy link

I would also really like this feature.

@leso-kn
Copy link
Contributor

leso-kn commented Mar 28, 2022

Update: This issue has been open for a while and I finally found some time to look into it again. I'd like to present a proposed implementation over at PR #1229.

Note: For the moment webcal subscriptions have to be added manually. The PR adds the relevant backend functionality for Radicale to advertise webcal subscriptions, internally stored as collections. A second step would be to add a more user-friendly way to add those subscriptions (e.g. via the Radicale web interface).

@MrPixelized
Copy link

Wow! I'm really shocked to see that the changes are that simple. Great work! :D

@mmBesar
Copy link

mmBesar commented Nov 17, 2022

This is the only feature missing, for me, in this great project.

@JadeVane
Copy link

JadeVane commented Sep 2, 2023

I second the request. There are still many people waiting for this feature after such a long time, I believe this feature needs to be put on the agenda.

@6801318d8d
Copy link

@Kozea can we at least merge the PR leso-kn #1229?

I second this FR

@pbiering
Copy link
Collaborator

pbiering commented Mar 3, 2024

#1229 merged into 3.2-devel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests