We believe that's the case. :-)
That is, we've implemented it, and have some tests, but since we
lack real clients that use it, it's hard to know for sure that the
implementation is satisfactory as-is. Obviously, we'd love to see
that change.
Note that some resources do not allow editing of ACLs. This may be
true for some of the base hierarchy (eg /calendars), since we don't
necessarily want to let those get into a "broken" state.
Additionally, your home calendar will give you DAV:all access which
is protected, meaning that you can't (that is, shouldn't be, unless
there is a bug) remove that privilege from a calendar home's owner.
The strategy that we've been pursuing to date in regarding ACL
controls for calendar resources and their containers is to avoid doing
ACL operations on individual calendar resources, and stick to editing
ACLs for calendar collections.
The server will allow you to do either, but I will bet that this
will confuse some, if not many, clients. ACLs are presently still a
pretty bleeding-edge concept, and I think getting too funky with them
may be tricky.
So things like giving a friend read access to a calendar should be
straighforward, but doing that for individual events has a lot of
oddball corner-case issues, I think. We think the server does sane
things here, but again, without real use cases, it's hard to know for
sure, and I don't expect that clients will necessary cope well.
Note also that we have a notion of "proxy groups". Each principal
on the server has two such groups associated with it, a read proxy
group, and a read/write proxy group. The ACLs are already set up
appropriately for these groups on each calendar collection, on the
theory that editing the group membership is simpler than monkeying
with ACLs. Again, real-world usage will bear out how well that
works. One limitation is that this applies to all of your calendars,
and not just some.
Hope this helps.
-wsv
On May 30, 2007, at 12:36 AM, [EMAIL PROTECTED] wrote:
Do you mean that CalDAV ACL are already implemented on the server
side ?
As far as i remember CalDAV ACLs are applicable not only on a calendar
object (which is a collection of events in webdav speaking) but ACLs
can
be set event by event.
Does Darwin Calendar Server implement this fully ?
The only problem to exploit this come from client side ?
—
Wilfredo Sánchez - [EMAIL PROTECTED]
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
