search

apple / ccs-calendarserver

The Calendar and Contacts Server.
https://www.calendarserver.org
Apache License 2.0
484 stars 136 forks source link

calendar for groups #497

Closed f1-outsourcing closed 6 years ago

f1-outsourcing commented 7 years ago

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

  2. 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?

  3. In what table in the database can I change this to 'accepted' calendar_bind.bind_status?

dreness commented 7 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 " to get help on a specific command. For this use case, we'll use the commands: share, notifications, calendars, user.

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.