Added support for webcal-subscriptions

[leso-kn]

This PR adds support for webcal subscriptions, as discussed in #776.

Please note, that this is a backend-focused implementation, so efforts to adapt the web UI have not been made in this changeset.

Webcal subscriptions can be added in the form of a collection, just like calendars, todo lists and the like. The URL to the targeted online ICS file, as well as the display name and an optional color for the calendar are stored in the .Radicale.props file of the regarding collection.

Steps to subscribe to a calendar manually:

1. Create a new collection (folder) in Radicale's collection-root/ directory
2. Create a .Radicale.props file, structured as shown in the example below

The subscribed calendar will now be advertised by Radicale and should appear in supported applications (e.g. DAVx⁵ for Android)

Example:

// cat collection-root/[...]/[a collection]/.Radicale.props
{
    "tag": "VSUBSCRIBED",
    "D:displayname": "Online Calendar",
    "ICAL:calendar-color": "#00BBEEFF",
    "CS:source": "https://example.org/online-calendar.ics"
}

Result (DAVx⁵ + ICSx⁵):

[lamyergeier]

@Unrud Please approve this pull request.

[dstrelnikov]

Since Radicale does not announce calendars which do not belong to the user but are accessible to read, this would be a very convenient workaround in my workflow!

[trougnouf]

I would like to share my existing Radicale calendars with a public (passwordless) read-only URL so that it works with google calendar and such.
Would this PR provide the solution or I should create a separate issue from #776 ?

edit: I think that was mostly irrelevant, and I got passwordless subscriptions working already by setting the following:

in /etc/radicale/config:

...
[rights]
type = from_file
file = /etc/radicale/rights
...

in /etc/radicale/rights:

# Allow reading root collection for authenticated users
[root]
user: .+
collection:
permissions: R

# Allow reading and writing principal collection (same as username)
[principal]
user: .+
collection: {user}
permissions: RW

# Allow reading and writing calendars and address books that are direct
# children of the principal collection
[calendars]
user: .+
collection: {user}/[^/]+
permissions: rw

# Allow access to public calendars and address books via HTTP GET for everyone
[public-calendars-restricted]
user: .*
collection: public/[^/]+
permissions: i

then create a public folder/user and symlink the relevant calendars to it.

[pbiering]

looks like at least not breaking anything

[OdinVex]

looks like at least not breaking anything

Tested with Apache, works fine. Repo org community site is 500, nothing else done to this repo since earlier mid-year.

[pbiering]

https://radicale.org/ is working, @Unrud : can you approve the pull request?

[OdinVex]

https://radicale.org/ is working, @Unrud : can you approve the pull request?

I meant their GitHub community site, https://community.kozea.fr/.

[leso-kn]

Update: Upstreamed to master to include latest changes, no merge conflicts.

ℹ️ As a side note: the Github Actions configuration seems to be broken though, it's using some outdated python version strings (see pipeline log and the list of supported python versions of the Github Actions module).

[MrPixelized]

Why hasn't this PR been merged yet? Is there anything I can do to help it along?

[govynnus]

Why hasn't this PR been merged yet? Is there anything I can do to help it along?

Same question here :)

[leso-kn]

Update: Upstreamed to master to include latest changes:

• Adapted code to use the new collection.tag-field.

Regarding my previous side note: I see the Github Actions configuration has been fixed, nice! :)
The pipeline is passing on my side.

Using that as a quick reminder that this PR is ready to be merged!

[leso-kn]

@Unrud Do you require any additional adjustments to this PR from my side?

[pbiering]

looks good, only extensions

[mmBesar]

If it's approved, Why it's not merged yet?!

[leso-kn]

@mmBesar There hasn't been much activity on this project lately. The last commit is from mid-April, so I believe the maintainer simply didn't have the time to look into it since this PR was approved.

In case you want to try out an alternative, you may want to check out https://sabre.io/baikal/.

[mmBesar]

@leso-kn I have Baikal installed.
Is it possible to subscribe to an online WEBCAL calendar?

[leso-kn]

@mmBesar According to https://sabre.io/dav/clients/ical/#subscriptions it should be possible, though it seems like you need to manually create the object (just like with this implementation for Radicale) or use a client that supports adding server-side webcal subscriptions (e.g. iCal).

[mmBesar]

@leso-kn Not available yet!
Check sabre-io/Baikal#1027
If you have any work around, please share.

[MatthewHana]

Had a look at the web UI and it wouldn't be difficult to add Webcal support to the UI that builds off @leso-kn's great work.

+1 for merging this PR.

[6801318d8d]

@Kozea can we merge please?

[pbiering]

ok

[pbiering]

@leso-kn : can you please create an empty commit to trigger "actions"? See here for more information: https://stackoverflow.com/questions/52408592/how-to-relaunch-github-check-without-pushing-new-commits

[leso-kn]

@pbiering done. Also rebased against master, which makes the docs job fail but that's only due to the branch name. All tests pass on all platforms.

[pbiering]

@leso-kn : I have requested enabling GitHub's Wiki for radicale, once enabled it would be great to have example documented there.

[gentooboontoo]

@pbiering @leso-kn Radicale's wiki has been enabled again.

[MatthewHana]

I have added support for this in the web UI in PR #1329. Thanks again @leso-kn.

[leso-kn]

@MatthewHana oh, Nice work! That's very cool