forked from extern/egroupware
1baa158195
- change the processing of slowsync, to use the content_map instead of trying to build a new one. This caused duplication issues on the client if multiple similar records where stored, because only the first one found in the server-db was matched, These duplicate entries at client side had no entry at serverside, so deleting the wrong one on the client (the content with a valid map entry) could cause unwanted data loss at server side, because it is impossible for the user to see what is a duplicate, and what is not. see also: http://www.nabble.com/again---syncml-duplication-issue-to20333619s3741.html - reenabled UID from syncml clients, because it was partly used this caused issues during SlowSync if the content was changed. - infolog, calendar if a uid is found in the provided data, allway try to find the corresponding content first using only the UID, instead of using the content-id taken from content_map. also fixed: - a few fixes in ./notes - creating an entry on the client that can not be imported, (Example, Nokia E Series Appointment without a Title) will no longer create an invalid content-map entry However, at client side this is still counted in the Protocol as Server-Add |
||
|---|---|---|
| .. | ||
| class.addressbook_bo.inc.php | ||
| class.addressbook_contactform.inc.php | ||
| class.addressbook_csv.inc.php | ||
| class.addressbook_display.inc.php | ||
| class.addressbook_groupdav.inc.php | ||
| class.addressbook_hooks.inc.php | ||
| class.addressbook_ldap.inc.php | ||
| class.addressbook_merge.inc.php | ||
| class.addressbook_sif.inc.php | ||
| class.addressbook_so.inc.php | ||
| class.addressbook_sql.inc.php | ||
| class.addressbook_tracking.inc.php | ||
| class.addressbook_ui.inc.php | ||
| class.addressbook_vcal.inc.php | ||
| class.boaddressbook.inc.php | ||
| hook_config.inc.php | ||
| hook_home.inc.php | ||