Calendar sharing support?

[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.