- expanded-group-member-set
- expanded-group-membership
- calendar-proxy-read-for
- calendar-proxy-write-for
Both calendar-proxy reports can be combined in one request, which is now also handled correct.
--> participants are - thanks to CalDAV scheduling - now setable for new event, thought searching for them does NOT yet work, no idea why ;-)
- added somehow missing calendar-query report to supported-report-set
- had to implement a workaround for Lightning, as it wrongly interprets principal-property-search for calendar-home-set in the principal-collection-set
matching our *DAV root returning all principals, as all have a matching calendar-home-set, as NOT supporting CalDAV scheduling
--> search only current user's principal, when Lightning searches for calendar-home-set
- OPTIONS / return now calendar-auto-scheduling too, as Lightning only searches there, to check if server supports CalDAV scheduling
- fixed outbox freebusy request to cope with no X-CALENDARSERVER-MASK-UID and a single attendee
- principal reports scheduling-inbox-URL /<username>/inbox/ and scheduling-outbox-URL /<username>/outbox/
- outbox collection contains no events
- outbox correctly answers POST for freebusy information
- outbox respons to all other POST with "204 No Content", ignore client request to deliver invitations
- inbox collection contains events of unknown status (PARTSTAT=NEEDS-ACTION)
- inbox responds to DELETE with "200 Ok"
--> iCal under OS X now shows freebusy times :-)
(had to add "write-content" privilege for calendar collections user has edit rights for, to allow adding events)
+ currently only standard WebDAV privileges: read, read-current-user-privilege-set, write-content, bind and unbind used
+ they get only queried for collections, thought we dont report any write* on collections, as we dont allow to create calendars or change properties
- new groupdav::add_resource() method used to add all resources (incl. collections) to propfind or report requests
- improved autoindex to show nicely indented hierarchical properties
- only define addressbook-home-set and calendar-home-set for principal-collections
- advertice /addressbook/ as addressbook-gateway (searchable collection for all contacts accessible to a user)
- Lightning pops up alarm, until Sequence/etag get updated: if user has no edit rights on an other users calendar, etag never got updated, now we update it
- fixed user was not able to add alarms via CalDAV, if he had no edit rights for event (was always possible in web UI)
- alarms from other users calendars are not included any more, as they make no sense but a lot of trouble
- fixed wrong condition on adding alarms, causing some alarms no being saved
Addressbook does NOT allow to specify the URL, unlike iCal which allows it after autodetection fails.
This, some XML specifics set now for Apple addressbook user-agents and etags for addressbook collection itself
allow now to use EGroupware with iPhone or Mac addressbook. The later was working before, if you edited the URL
into a decompiled plist file, but failed now because of a new REPORT it tries on the principal, to find out shared
addessbooks, which we not yet support, but failed to tell in the correct way (501 Not Implemented).
Addressbook sync now the personal addressbook, because that is what we tell it as addressbook-home-set.
We should add some configuration so user can choose what addressbook to set as addressbook-home-set, or to set
the "all" addressbook (/addressbook). For the later we could add some prefs like SyncML to specify filters or
eg. a distribution list.
