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.bocalendar.inc.php | ||
class.boholiday.inc.php | ||
class.calendar_ajax.inc.php | ||
class.calendar_bo.inc.php | ||
class.calendar_boupdate.inc.php | ||
class.calendar_datasource.inc.php | ||
class.calendar_groupdav.inc.php | ||
class.calendar_hooks.inc.php | ||
class.calendar_ical.inc.php | ||
class.calendar_sif.inc.php | ||
class.calendar_so.inc.php | ||
class.calendar_ui.inc.php | ||
class.calendar_uiforms.inc.php | ||
class.calendar_uilist.inc.php | ||
class.calendar_uiviews.inc.php | ||
class.holidaycalc_JP.inc.php | ||
class.holidaycalc_US.inc.php | ||
class.holidaycalc.inc.php | ||
class.sbox.inc.php | ||
class.soholiday.inc.php | ||
class.uiholiday.inc.php | ||
events.ics | ||
gradient.php | ||
round_corners.php |