--> 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)
Plan is to run a clientside cache and own queue for link_titles, as server can query titles for N id's for a given app more effiently then N separeate queries.
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()
- sending EGroupware configuration (non-sensible stuff) to browser and make it available via egw.config(_name, _app="phpgwapi")
- sending link-registry in the same file
- used javascript file uses etag to ensure there's no need to load it on each request
- arrays in $GLOBALS[egw_info][server] are now automatically serialized and unserialized
- new static method to check if user is export-limit excepted
--> saves to query it on each request (for non-phpgwapi, which was already cached in the session)
- setting preferences on server via egw.set_preference(_app, _name, _value)
- enable calling of active framework / template class via using egw_framework instead of not known used framework class of user, eg. "home.egw_framework.ajax_func.template" instead of "home.idots_framework.ajax_func.template"
- egw.preferences(_name, _app='common') return preference _name of _app (only common prefs loaded currently)
- egw.open() allowing to open app-entries utilising the link registry, deprecating egw_open from jsapi.js
- egw.lang(_msg, _arg1, ..., _argN) placeholders are not yet implemented
setting headers to allow browser to cache the file until it's etag containing the creationdates of the used langfiles changes
--> et2 can now use egw_lang object to translate labels, options, ...
(previously only moving from a page up to the cat, then up globally was
possible).
- Allow options within a select to be formatted through the standard
html::select_option() function
