Closed f1-outsourcing closed 6 years ago
The method described in the macworld post doesn't work anymore. One way to achieve a similar result is to use a resource account to own the calendars, and then share them to users via the invitation workflow. You can also grant read-only or read-write delegate access (this is account-wide, unlike sharing which is per collection), however delegation isn't supported on iOS.
We do have a notion of groups as (mostly) first-class principals, however that's all fairly complicated and we never did end up using it (read: there are surely some bugs here). If you want to mess with this, check out these various settings:
https://github.com/apple/ccs-calendarserver/blob/master/conf/caldavd-stdconfig.plist#L994 https://github.com/apple/ccs-calendarserver/blob/master/conf/caldavd-stdconfig.plist#L1475 https://github.com/apple/ccs-calendarserver/blob/master/conf/caldavd-stdconfig.plist#L2101
There is no support for "auto accept" of sharing invitations (although there is support for automatic behaviors related to scheduling invitations). So, the receiving user needs to accept a calendar sharing invitation.
There are at least a couple ways you could build an auto-accepter for sharing invitations. One way would be to use CalDAVClientLibrary, which includes a command line shell and various commands. Note that this isn't quite able to do what you want without some modifications, but you may choose to make those changes or simply use it to learn more about how sharing works so you can write your own thing. CalDAVClientLibrary requires many of the same python depencies that CalendarServer does, so if those deps aren't available system-wide, you can start it like this from the CalendarServer source code directory using the project's python entry point (shell script):
./bin/python subprojects/caldavclientlibrary/runshell.py \
--server=https://server.example.com:8443/ --user=andre
Once logged in, type "?" to see the list of commands, and "help
Let's send a calendar sharing invitation from 'andre' to 'luser', then accept that invitation as 'luser'.
╭─ andre@zomg ~/work/ccs-calendarserver
╰─ $ ./bin/python subprojects/caldavclientlibrary/runshell.py --server=https://example.com:8443/ --user=andre
Password:
/ > calendars
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/ > ls
calendar/
dropbox/
freebusy
inbox/
notification/
outbox/
tasks/
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/ > cd calendar
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar > share
Organizer: (None)
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar > share -i
Entering sharing edit mode on resource: /calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar/
Share > ?
add - Add invite to existing resource.
change - Change invite on existing resource.
exit - Terminates this session.
help - Displays help about a command.
list - List current invitees on existing resource.
logging - Changes the current state of HTTP logging.
quit - Terminates this session.
remove - Remove invite on existing resource.
Share > add
Enter principal id: /principals/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8
Read or Read-Write Mode [r/w]: [w]:r
Summary: [Shared]:hullo
Share > list
Organizer: (None)
1. luser (urn:x-uid:4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8) Invite: no-response Access: read Summary: -
Share > quit
Exiting shell: quitting
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar > whoami
andre
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar > cd /
/ > user
New User: luser
New Password:
/ > calendars
/calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/ > ls
calendar/
dropbox/
freebusy
inbox/
notification/
outbox/
tasks/
/calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/ > notifications -i
Entering notifications edit mode on resource: /calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/notification/
Notifications > list
1. Sharing Invite: From: andre (/principals/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/) Access: read Summary: hullo Host-URL: /calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar
Notifications > ?
accept - Accept an invite.
decline - Decline an invite.
delete - Delete notification resource.
exit - Terminates this session.
help - Displays help about a command.
list - List current invites for user.
logging - Changes the current state of HTTP logging.
quit - Terminates this session.
Notifications > accept
1. Sharing Invite: From: andre (/principals/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/) Access: read Summary: hullo Host-URL: /calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar
Accept invite at [1 - 1] or cancel [q]: 1
Notifications > quit
Exiting shell: quitting
/calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/ > ls
1f8c11b3-55d5-4edb-ac3d-887694e84ed8/
calendar/
dropbox/
freebusy
inbox/
notification/
outbox/
tasks/
/calendars/users/luser > cd 1f8c11b3-55d5-4edb-ac3d-887694e84ed8
/calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/1f8c11b3-55d5-4edb-ac3d-887694e84ed8 > props -p {DAV:}owner
OK Properties:
{DAV:}owner: URL: /principals/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/
/calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/1f8c11b3-55d5-4edb-ac3d-887694e84ed8 > user
New User: andre
New Password:
/calendars/__uids__/4E1BA0D8-611B-4C18-A4DB-B921E0EBA7D8/1f8c11b3-55d5-4edb-ac3d-887694e84ed8 > calendars
/calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/ > notifications -i
Entering notifications edit mode on resource: /calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/notification/
Notifications > list
1. Sharing Reply: From: mailto:luser@example.com Result: accepted Summary: - Host-URL: /calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar
Notifications > ?
accept - Accept an invite.
decline - Decline an invite.
delete - Delete notification resource.
exit - Terminates this session.
help - Displays help about a command.
list - List current invites for user.
logging - Changes the current state of HTTP logging.
quit - Terminates this session.
Notifications > delete
1. Sharing Reply: From: mailto:luser@example.com Result: accepted Summary: - Host-URL: /calendars/__uids__/77F4771B-B421-4590-9C8F-D84DF323C7EA/calendar
Delete invite at [1 - 1] or cancel [q]: 1
Notifications > list
No notifications.
Notifications > quit
Exiting shell: quitting
Of course, as shown here this only works if you can log in as the other user. CalendarServer has an "AdminPrincipal" facility that allows an administrator to act as another user, however CalDAVClientLibrary doesn't seem to allow this to work in all cases. For example, as 'andre' (an AdminPrincipal) I can cd into another user's calendar, and then use 'share' to send a sharing invitation to a third user, which appears to that user to have been sent by the calendar's owner. However, the 'notifications' command seems to want to look up the authenticated user's notification URL, and the optional "PATH" argument doesn't seem to work. Seems like it should be fairly straightforward to fix this, but I haven't tried yet. Also note that you can use the 'cat' command to see the full body of an existing notification, which might be useful if you want to generate your own sharing requests and responses.
As far as the DB, it should be possible to manually force the status to accepted, although you'd also want to delete the associated notifications. The bind modes are represented as integers, and are drawn from the table calendar_bind_mode. Here's a couple queries to get you started:
# list a user’s shared calendars
SELECT owner_uid,
calendar_resource_id,
calendar_resource_name
FROM calendar_bind
left join calendar_home
ON calendar_bind.calendar_home_resource_id =
calendar_home.resource_id
WHERE bind_mode != 0
AND owner_uid = 'B6D75AB6-63D9-433F-850D-A2FC447FF23C';
# set a calendar_bind status
UPDATE calendar_bind
SET bind_status = 3
WHERE calendar_resource_name = '6e565580-7d37-4517-99a8-27da97e7290d'
AND calendar_home_resource_id IN (SELECT resource_id
FROM calendar_home
WHERE
owner_uid = '2990D10E-8A5A-6540-B2C1-DBFFEE6FDC22');
Note that sharing is one of the simpler workflows, where the side effects are few and easy to understand. Most of the stuff that CalendarServer does should only be attempted through CalDAV and not direct database manipulation.
Is it correct that the group calendar does not exist anymore? The group is only used for permission purposes and grouping users? Eg. http://servername:8008/principals/groups/groupname/ is dropped? As mentioned in eg: http://hints.macworld.com/article.php?story=20080410162942908 https://github.com/apple/ccs-calendarserver/issues/311
if I share an calendar in osx calendar. I have question mark next to the account in shared with. I guess this is related to an invitation. Is it possible to 'auto accept/allow' this?
In what table in the database can I change this to 'accepted' calendar_bind.bind_status?