Evert
Unfortunately that feature was removed in 10.8. So there's no way to do the same thing there..
Evert
Evert
The delegation looks correct: |
The same happens when I change the table the following way:
groupmembers
id principal_id member_id
3 13 7
4 16 1
5 8 1
So I think at some point the principal_id and the user_id are mixed up. Can some reproduce that behavior with either Baïkal or SabreDAV?
All the best,
Raphael
Hi,
I am writing here as I don't know if this is an issue with SabreDAV or Baïkal. I followed the wiki and added some proxy entries to test the calendar delegation and it works with my setup (Baïkal + OSX 10.9/iOS 7). The problem is: it works a little bit too well. My account gets read-/write-access to calendars the given user shouldn't get. As I can trigger this behavior it should be fairly easy to fix (either witin Baïkal or SabreDAV).
These are the delegation I see on Mac OS (for my user with the ID=1):
[snip]
Thanks for the detailed information, but in this case I think the problem is straightfoward. In the groupmembers table, both the principal_id and member_id refer to principals. They _never_ refer to users.
The users.id field is never used in the entire codebase (as far as I'm aware).
principal_id should refer to the parent (in the case of calendar-proxy, this is always a 'proxy principal'), member_id should refer to the id of the principal of the user.
Your principals table should for every user have 3 principals:
1. The base principal: principals/username
2. The write principal: principals/username/calendar-proxy-write
3. The read principal: principals/username/calendar-proxy-read
Hope this helps,
Evert
Thanks for the detailed information, but in this case I think the problem is straightfoward. In the groupmembers table, both the principal_id and member_id refer to principals. They _never_ refer to users.