On Nov 11, 2014, at 2:17 PM, Axel Siebenwirth <cal@mooselook.de> wrote:
Hi,
I've set up a group consisting of two members.
<group> <uid>katjaaxel</uid> <password>diavCiv8</password> <name>Users Group</name> <members> <member type="users">axel</member> <member type="users">katja</member> </members> <guid>734BB9B0-0298-5853-9F6F-1E68322A866B</guid> </group>
Very simple and stupid question: What is the URL to access the group calendar?
I see what you’re trying to do, and it would be cool if that worked. The fact that the group record type supports a password attribute is a hint that this did work once upon a time, but no longer. You created a ‘directory services’ group with the above XML definition, similar in concept to a unix group. It is simply a named collection of users, and does not provision a group calendar. All calendars have to be owned by a “principal”, which is a CalDAVish term for "account". A group is a principal, but we do not allow groups to own calendars. The kinds of principals that can own calendars are: user, location, resource. Some ideas: 1) A user shares one or more calendars to other users. This is the same technique that can be used between iCloud calendar users. Right-click on the calendar name and choose “Share Calendar...”, then enter another user’s username. 2) Create a resource principal which will own the calendars you wish to share. Use calendarserver_manage_principals to grant read / write delegate access to one or more users, then those users can create calendars in the resource’s account. To provide these resource-owned calendars to other users, you can share them to other users as the r/w delegate. 3) Use r/o or r/w delegation instead of sharing. The best approach for you depends somewhat on which clients you are using, as support for shared calendars and delegated calendars varies by client. We have a very new feature that implements groups as first-class attendees, so that when you invite a group, instead of expanding the group to a list of users and then inviting individual users and encoding the users into the iCalendar data, the group principal is encoded into the iCalendar data instead. The server tracks the group over time to add or remove attendees on the event as group membership changes. Also included in this feature is the ability to share a calendar to a group; the server does the same kind of group membership tracking, but instead of adding / removing attendees from events, it creates or removes shared calendar bindings. CAUTION, CAUTION: This feature is very new and is completely unused (as far as we know ;). There are probably bugs. Did I mention this is a new feature? Well, it’s very new :) If you are brave and strong, you can play with this using either our trunk code or CalendarServer-6.0-dev <http://trac.calendarserver.org/browser/CalendarServer/branches/release/CalendarServer-6.0-dev> (which will probably get tagged as a release any time now...). The relevant caldavd.plist keys are: GroupAttendees:Enabled and Sharing:Calendars:Groups:Enabled In OS X Server, a real group calendar is a supported feature via the Wiki integration. In that model, a wiki is treated as a valid calendar principal via some special glue, and users are able to access calendars owned by the wiki via the web interface. For open source (which lacks the wiki), groups cannot own calendars, so you need to use one of the above tactics. Hope this helps, -dre
For my own calendar it's host:port/calendars/users/axel/calendar
Thanks in advance, Axel _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users