Calendar sharing support (3.7.0+)

[tonioo]

According to #596, calendar sharing is not supported.

Is there any plan to add support for this?

[Unrud]

Is there any plan to add support for this?

Yes, but #188 (comment)

[tonioo]

@Unrud When you talk about "real calendar sharing", do you mean https://www.calconnect.org/resources/7-things-you-should-know-about/calendar-and-contacts-sharing ?

[Unrud]

The calendar sharing will be transparent to the client and can be configured in the built-in web interface.
Exclusive VALARM components for every user are not planned.

[djmattyg007]

I've been looking at the code to see what might be required to implement calendar sharing. From what I can tell, the major hurdle at the moment is that the code relies on navigating a filesystem that maps to the URL paths used by clients, and expects all collections to be inside a folder for the user who created them.

An alternative structure that would lend itself better to calendar sharing could be to get rid of the user folders altogether, and store all collections in a single folder. The owner of a collection would be stored alongside that collection, and each user would also have its own config file that lists which collections it has access to (and whether or not it has read or read/write permissions).

If implemented correctly, it should also allow for alternative storage backends to be implemented. For example, instead of storing files on disk, data could be stored in a database, or AWS S3, or something else entirely.

@Unrud What are your thoughts?

[thenktor]

I also need calendar sharing, so thumbs up for this feature request 👍

BTW: Sharing seems to work with symbolic links on the file system. Is there a reason why I should not use it that way?

[kaie]

Another way to share is to create a separate user account, create a calendar for that shared user, and share the login between all the users that are allowed to access/modify, right?

[pavinjosdev]

share the login

@kaie Sharing passwords is frowned upon, I did some tests with @thenktor's symlink method and it seems to work fine even when two users are simultaneously editing the same calendar.

[thenktor]

The symlinking method works for me with two users since my last post. I did not have problems so far.

[Jip-Hop]

Does the symlink workaround still work? I'd like to make a calendar to share with my partner. I tried:

ln -s /data/collections/collection-root/user1/4d52f15d-9703-123f-8844-ad7f70af5f48/ /data/collections/collection-root/user2/4d52f15d-9703-123f-8844-ad7f70af5f48/

But the calendar is not showing up when I login as user2.

By the way, I'm using: https://github.com/tomsquest/docker-radicale which uses Radicale v3.1.2.

[donfede]

Does the symlink workaround still work? I'd like to make a calendar to share with my partner. I tried:

Yes, had recent success using the symlink workaround (radicale 3.0.6-3 from Debian 11; DAVx5 v4.1-ose from fdroid).

First created the shared calendar with one user, then made the symlink on the server, and last ran Refresh calendar list on the second user's phone (DAVx5/ CALDAV tab/ top right three buttons menu).

Sample directory layout to compare:

$ pwd
/var/lib/radicale/collections/collection-root
$ ls -l *
userA:
total 12
drwxrwxrwx 3 radicale radicale 4096 Jan 26 18:21 07d2d2bb-7e94-4efa-a366-51eea0091997
drwxrwxrwx 3 radicale radicale 4096 Jan 24 19:58 731c49da-aad0-44dc-beb0-3ff44d8295f3
drwxrwxrwx 3 radicale radicale 4096 Jan 23 13:30 ed2cef32-d744-4633-b694-c7d0eba34d59

userB:
total 28
lrwxrwxrwx 1 root     root        48 Jan 24 19:31 07d2d2bb-7e94-4efa-a366-51eea0091997 -> ../userA/07d2d2bb-7e94-4efa-a366-51eea0091997
drwxrwxrwx 3 radicale radicale 20480 Jan 25 14:55 675192be-fc0d-4f25-9ba6-c5a7f3a11a3c
drwxrwxrwx 3 radicale radicale  4096 Jan 25 13:46 c3e23fb4-60c7-4cd3-9b5e-18acac18f5ea
$

[Jip-Hop]

Thanks @donfede for showing your directory layout. Made me realize I mad the symlink in the wrong way. Should have done it like this:

ln -s /data/collections/collection-root/user1/4d52f15d-9703-123f-8844-ad7f70af5f48 /data/collections/collection-root/user2/
chown -h radicale:radicale /data/collections/collection-root/user2/4d52f15d-9703-123f-8844-ad7f70af5f48

Now the shared calendar shows up and both users can create/delete appointments. 🙂

[juvenalandres]

Thanks @donfede for showing your directory layout. Made me realize I mad the symlink in the wrong way. Should have done it like this:

ln -s /data/collections/collection-root/user1/4d52f15d-9703-123f-8844-ad7f70af5f48 /data/collections/collection-root/user2/
chown -h radicale:radicale /data/collections/collection-root/user2/4d52f15d-9703-123f-8844-ad7f70af5f48

Now the shared calendar shows up and both users can create/delete appointments. 🙂

I'm trying to share one of my calendars using the https://github.com/tomsquest/docker-radicale image, but with no success. Could your share your docker-compose.yaml please? It might have something to do with user rights, but can't figure out what is missing.

Thanks

[kowabungaboy]

Thanks @donfede for showing your directory layout. Made me realize I mad the symlink in the wrong way. Should have done it like this:

ln -s /data/collections/collection-root/user1/4d52f15d-9703-123f-8844-ad7f70af5f48 /data/collections/collection-root/user2/
chown -h radicale:radicale /data/collections/collection-root/user2/4d52f15d-9703-123f-8844-ad7f70af5f48

Now the shared calendar shows up and both users can create/delete appointments. 🙂

I'm trying to share one of my calendars using the https://github.com/tomsquest/docker-radicale image, but with no success. Could your share your docker-compose.yaml please? It might have something to do with user rights, but can't figure out what is missing.

Thanks

I managed to do that within the container. For me it was similar to
docker exec -it --user radicale radicale sh
Then you do the same ln commands just with the paths within the container. That should give you broken links on your host machine but in works within the container. Hope it helps, best regards

[BrunoBernardino]

For someone looking for a "simpler, no-code way", what I've done is create a "shared" user which my wife and I use for the shared calendars and tasks list, and then we have our own users with our "private" ones. We simply connect with the two users, and everything works as expected.

[pbiering]

For someone looking for a "simpler, no-code way", what I've done is create a "shared" user which my wife and I use for the shared calendars and tasks list, and then we have our own users with our "private" ones. We simply connect with the two users, and everything works as expected.

This can also be done by softlinking, either one to another or from a "hidden" group directory.

[geomule]

Surely calendar sharing has now been implemented? Of course, creating a "family" user would allow sharing calendars but seems overkill to me. It should be as simple as adding a tick box on the web interface to share a calendar and then the other users are listed. I think you can use the "Rights" to tweak calendar sharing but I can't get my head around it.

[pbiering]

Implementing a "user-friendly" sharing capability requires a bunch of rework in the permission control area and potentially even storage area. This is a bigger task and would require contribution.

[applesoff]

recently wrestling with this as well. i can get config to point to rights config file, but fail after this. Do i need to change the rights type to from_file and then set it in the rights config? when i change the rights file management type to from_file i am unable to log my user in to the server. i find the rights config to be confusing. any help on this would be appreciated.

[BK-20]

I want to use radicale to get away from sharing at the file system level. My experience is that the file system does not resolve concurrent accesses, so that random data loss or corruption occurs from time to time. Therefore, the symlink method is not a permanently satisfactory solution.
The configuration in text files is user-friendly enough for me if it is sufficiently documented. Example:

Tom and Sabine r/w in Family

[family-shared]
user = sabine
collection = tom/12dded19-117a-48c3-9812-affa11c0ccb4
permission = rw

Sabine r/o in Tom

[tom-ro]
user = sabine
collection = tom/b0d3975a-3aaa-43fa-8b32-4f8e239fd664
permission = r

If this works, I'm happy with it.

[pbiering]

I've reviewed the Wiki now related collection sharing and updated

https://github.com/Kozea/Radicale/wiki/Sharing-Collections

Your configuration from above is not that far away, but you miss the softlinks..."radicale" is not supporting lookup of directories outside the authenticated user's base directory, but honoring softlinked ones quite well.

[pbiering]

I'm using this since years, and hope that "radicale" take care of....as it also has to cover multiple CalDAV/CardDAV connections of a single user (e.g. MobilePhone 1...x, fat e-mail client 1...x). And storage is per item and usually UUIDs are used per file name.

[bigretromike]

question would be how many concurrent simultaneous edits need to occur to radical have issue with sharing same file for multiply clients.
been using shared calendar for years, but to be honest it only for 2 people on max 4 device and never I did try to edit something from multiply devices at same time.

[pavinjosdev]

We've been using Radicale in production at Mailcheap for many years with the symlink sharing method for addressbooks and calendars. No issues with concurrent access so far. 🍃

[BK-20]

If in doubt, two simultaneous write accesses are sufficient: the last one to finish wins. If the whole calendar is corrupted in the process, it is immediately noticeable, but if a single change is overwritten or deleted, you only notice it when it is too late. This has happened to me several times in recent years when using *.ics files that were synchronized via FTP. So I wanted to leave this to a specialized server, and I wonder how radicale ensures that the data is always intact when control only takes place via the file system.

[pbiering]

Every upload (PUT request) is parsed by "radicale", if not valid, it will be rejected before storing in file system => collection on file system should never reach a broken status except something crashes in the middle.

And regarding "latest-write-win": please read all related RFCs, I'm not aware that any locking/release is defined here, so this can be simple "standard" behavior.

BTW: "radicale" is open source and freeware, so feel free to dig also through the code and if you have still fears, then (find someone who) write test cases around to test such.

[dawidmachon]

Any chance or plans for any group aware collections or shared calendars between multiple users?

[pbiering]

No plans beside static sharing which is documented here https://github.com/Kozea/Radicale/wiki/Sharing-Collections because this would turn radicale from a lightweight into a complex solution imho.

[alien999999999]

since eg ldap has group membership, having collections-shared/<groupname>/ next to collections-root/<username>/ would not be too complex imho to combine all uniquely in both folders for each group where user is part of, when user logs in should not be too complex nor slow it much down, especially since you can turn it off with group config. i guess it's a slippery slope, but this would make less management needed... i guess the rights would also need to be adjusted for group/user rights, maybe?

[Darin755]

In the UI would it be possible to add a public security setting? It would be nice if there was a way to share a link that could be read unauthenticated. Instead of dealing with complex permissions you could just allow for links that have a credential in the URL.

[momsi]

Disclaimer, I've not read the whole discussion and all the past issues concerning calendar sharing, but I've got another easy solution to calendar sharing if you use Docker (compose).

You can simply map the data folders like so:

volumes:
  - host.../data/collections/userA:container.../data/collections/userB:rw

alternatively, for more than one user, use a dummy folder on the host:

volumes:
  - host.../data/collections/dummy:container.../data/collections/userA:rw
  - host.../data/collections/dummy:container.../data/collections/userB:rw
  - host.../data/collections/dummy:container.../data/collections/userC:rw

Concurrent editing of the same element might be problematic, though.

[chrysn]

The way I've used sharing over the last years (ever since I switched over from calypso) was to set up the appropriate rights, and then give the client the full path to the shared calendar. I.e., I'd log in with my user chrysn, and while all applications would only show me my calendar and my contacts, when given the full path https://my-server/otheruser/calendar/, things do still work. (It's just tedious to set up without autodiscovery, and eg. in DAVx⁵ it means running a dedicated DAVx⁵ "account" per calendar).

The symlink trick (chrysn/otheruser-calendar -> ../otheruser/calendar) is a great simplification for me, thanks for pointing it out; it also does away with the need for setting up differentiated permissions. It sounds a bit odd to have the same resource hosted at different URIs (i.e. to create aliasing), but that might be a consequence of WebDAV's stance on principals and only discovering resources under that principal's location (but it's been some time since I've read that standard, and never fully understood it).

[Cantello]

Question regarding sharing calendars: The instructions in the wiki state to "create a sub-directory structure with collections or group->collections", which apparently include creating a calendar there in order to be able to share something. How would I go about this if I wanted to create a new calendar to be shared (rw) amongst family members?

I now have the following structure:

collections/
├─ collections-root/
│  ├─ member1/
│  ├─ member2/
collections-shared/
├─ shared-family-calendar/ (symlinked to member1 & 2 above)

How could I populate the symlinked folder with an actual calendar?

[nicokaiser]

I'd move the collections-shared inside the collections folder alongside collections-root, but that's just cosmetical.

So inside the members1 and members2 directories are symlinks to the shared-family-calendar, right?

collections/
├─ collections-root/
│  ├─ member1/
│  │  ├─ shared-family-calendar -> ../../collections-shared/shared-family-calendar
│  ├─ member2/
│  │  ├─ shared-family-calendar -> ../../collections-shared/shared-family-calendar
├─ collections-shared/
│  ├─ shared-family-calendar/

To actually make the shared-family-calendar usable, you need to create a .Radicale.props file inside of it:

{"C:supported-calendar-component-set": "VEVENT", "D:displayname": "Family Calendar", "tag": "VCALENDAR"}

Now all members should see the calendar and can create and edit events.

Two notes:

• All members can also edit the calendar itself (its display name, color and order in the clients). These changes are also shared (no indivitual name/color/order for the members).
• Members can "delete" the calendar. When members1 deletes their instance of the Family Calendar, only the symlink is deleted. When this happens accidentally, someone needs to "restore" the calendar by simply re-create the symlink.

(I think both can be prevented when using a from_file rights entry in the config, but then you need to explicitly declare the calendars and their permissions, which of course makes things more complex. However that way you can also implement read-only calendars)

[alien999999999]

a way for this to do in management would not be amiss; can already make calenders, just now making group calenders in the interface, maybe a way to manage the "groups" in collections/ (folder named collections-<group> ), then a way select users to be "subscribed" to calendar (making symlink). all this for the admin user only?

[pbiering]

calendar sharing is currently only supported by workaround as described in Wiki and working on Unix filesytems only.

There is long running PR open to get this implemented but nobody so far had time to adapt the old proposal to current code: #885

A web interface manipulating softlinks on the filesystem is not a solution as it e.g. will not work on Windows OS.

[alien999999999]

is that even required? who would run something like this on a windows? wouldn't it make sense to start it working for unix and just someone else can do the windows part if someone wants to?

[41D5K1N6]

Ok guys, I give up. Ive tried to set up one shared calendar between 2 users on my server, but I just cant seem to figure out the right config. My tree looks like this:

|-- collection-root
| |-- user1
| | |-- collection1
| | |-- collection2
| | | '-- ee41e027-0375-4070-9d3e-030a95612636.ics
| | |-- collection3
| | | |-- someeventsX.ics
| | |-- sharedcollection -> collection-shared/sharedcollection/
| | '-- collection4
| | |-- d1ab5fac-3f82-484d-a168-c44fca75097e.ics
| | '-- f2502f1e-a4de-48a9-8abd-af1456bbca9e.ics
| '-- user2
| '-- sharedcollection -> collection-shared/sharedcollection/
'-- collection-shared
'-- sharedcollection
'-- 3256ae8b-9b7a-412b-8266-62be8874beff.ics

my rights like so:

[root]
user: .+
collection:
permissions: R

[principal]
user: .+
collection: {user}
permissions: RW

[calendars]
user: .+
collection: {user}/[^/]+
permissions: rw

[shareduser1]
user: user1
collection: {user}/sharedcollection(/.+)
permissions: rw

[shareduser2]
user: user2
collection: {user}/sharedcollection(/.+)
permissions: r

I've ran chown radicale:radicale and chmod 775 under /path/to/collections, but the shared calendar just doesnt want to show up anywhere, i.e. neither on the web-client, nor on any DAVx5 device. I apprechiate all the help and please do tell if i should share any logs. Thank you all in advance.

[pbiering]

Your softlink is imho buggy because relative but ../../ prefix missing...run

find collection-root/ -type f -follow -name .Radicale.props

to find all property files and then fix beside softlink also your directory structure

You provided

'-- collection-shared
'-- sharedcollection
'-- 3256ae8b-9b7a-412b-8266-62be8874beff.ics

but this should be imho

'-- collection-shared
'  | -- sharedcollection
'          -- 3256ae8b-9b7a-412b-8266-62be8874beff.ics

[41D5K1N6]

Ahhhh yws the issue was I made the softlink with relative paths, not absolute ones.... thanks for pointing that out!
In my original post the directory structure got screwed, it is as you pointed out.

Again, thanks for your help!

[bigretromike]

its been 9 years, are we sure we want to deal if used with more than 2 people ?
I hope we will see it someday .
It was already removed from roadmap

[pbiering]

It's not that easy in this lightweight implementation to add sharing by-map or also by-token, but I've started now a new design discussion: #1978

[bigretromike]

would be awesome

[pbiering]

Try now beta status of sneak preview in #1978

[pbiering]

sharing support added to upstream/master, any follow-up add to #1978