not sure why I used $this->bo->account_repository != "ldap", it makes no sense, as we specify the column explicitly, no idea if CardDAV works for an addressbook in LDAP, but now it works for accounts in LDAP too
+ 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
caused by not longer necessary special handling of contact_id in addressbook_sql, which is handled now in so_sql(_cf)
fix for PostgreSQL to NOT get SQL error ORDER BY must be in column list for GroupDAV/CardDAV propfinds
- 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
- include deleted contacts in ctag generation, as otherwise deleting entries does NOT change ctag
- implemented AlterPingChanges using ctag for ActiveSync
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.
allow to do propfinds on hugh addressbooks independent of memory_limit:
- regular groupdav_handler::profind() method gets split in a method just
computing a filter and a callback to run that filter on the backend
- groupdav_propfind_iterator class is returned from profind method
instead of an array with information about the files
- iterator calls groupdav_hander::propfind_callback if there are no more
entries from the previous call
- constructor of groupdav_propfind_iterator allows to pass an extra array
with files to return, to simplify modifying existing implementation
(were eg. information about the current path, get's supplied from
calling groupdav class).
Patch is mostly created by script in egroupware/doc/fix_depricated.php in separate commit.
I do NOT advice to apply this patch to a production system (it's commited to trunk!), as the automatic modified regular expressions have a good change to break something ...
manufacturer and the recogniced GroupDAV client as product name.
This way we are able to handle different GroupDAV clients, as we
allready do with different SyncML clients.
Also removed the no longer needed code enabling the use of the real UID,
as SyncML does no longer misuse the UID for it's GUID.
- new entry were not handled correct after the last commits (201 Created and Loaction header)
- cadaver reports entires as not found, because modified and contentlength were not set"
- using uid as filename to improve the support of newer SOGo connectors (>= 0.62), which require the server to remember the path they used to store a new contact
--> still not working reliable and causes TB to lock up
--> recommended is still version 0.62 of the SOGo connector "
addressbook (infolog will follow).
CalDAV is tested so far with lightning 0.8 and Apple's iCal. Please note
that both distinguish between iCalServer and CalDAV!
The URL is currently http://domain.com/egroupware/groupdav.php/calendar/
