--> 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)
a) instead of a single request like: new egw_json_request(menuaction, params).sendRequest(true, callback, context);
b) you call: egw.jsonq(menuaction,params,callback,context)
The server callback is identical for both kinds of requests. All egw_json_response methods can be used and the callback is optional.
- changing config in setup did not update or unset the cache --> instance was NOT using it
- new installs failed, because cache was not configured
- cache command to not configured cache gave fatal error, now they throw a (catchable) exception
- fixed not working vfs-image-dir
- deleteing image-maps when:
+ apps get installed, updated or removed
+ admin >> register hooks
+ admin >> site configuration: vfs-image-dir get changed
- fixed not displayed validation errors (thought there were no validation) in admin >> site config
--> you need to register hooks, in order to get the admin >> site configuration validation hook ;-)
egw_cache::get_provider(Instance) no provider found (error instanciating provider egw_cache_files: egw_cache_files::__construct() server/temp_dir
--> made egw_cache::get_config_value public, so egw_cache_files can use it and for regular egw sessions read install_id and temp_dir together with system_charset, before calling config::read()
