Resolving Delete Conflicts After Resynchronizing
During single-row editing, deleting an item removes it from the view permanently. During multiple-row editing, deleted items display in the view when pending deletes are turned on. For more information, see
Showing and Understanding Pending Deletes During Multiple-Row Editing.
After resynchronizing, if you deleted an item that was somehow modified on the server, the deleted item displays regardless of whether Show pending deletes is turned on because of a conflict. This allows you to see that something on the item has changed and confirm that you still want to delete the item.
For example, assume that X represents a content row that you have deleted from the document on the client. However, this same item in the document on the server was moved from its original location after you opened the document for editing.
After you resynchronize the document, this deleted item displays in the view, even if pending deletes is turned off. It displays in light gray type, and a
Removed label replaces the section number. A conflict icon
is shown in its row header. If enough room is available, the deleted item icon
also displays.
When you click this row, an information message is shown at the top of the editable item preview. The message indicates that you deleted this item, but this item, or one or more of its children, was moved after you began your edit. The message also indicates that by reviewing this message you are confirming that the item is to remain deleted. If you later decide to restore this deleted item, you use the
Restore Deleted Content action. For more information, see
Restoring a Deleted Item After Resynchronizing.
Conflicts Related to Deletes
Assume that X was deleted on the client. Here are the ways in which different delete scenarios are handled:
• X was also deleted on the server.
◦ No conflict is shown. For this case, X gets deleted regardless because its deletion has already been committed on the server and cannot be undone. The client-side request to delete the item is simply ignored. The client is not informed in any way that the delete operation was not performed because the item was already deleted on the server. Additionally, the audit log does not show an entry for the client-side attempt.
• X was moved on the server or X’s parent was moved on the server.
◦ A conflict is displayed on X, notifying you of the move.
◦ X appears in its moved location, but it is rendered as deleted.
• X’s structure has changed on the server due to the insert, delete, or move of content items.
◦ A conflict is displayed on X, notifying you of the structural change.
◦ X is rendered as deleted. All items under X are also rendered as deleted, including any new items added to X.
• X was modified on the server.
◦ A conflict is displayed on X. The information message for this conflict notifies you of the modification. You can review the field modifications within X. X is annotated with an exclamation point (!) in the item. This is similar to how conflicts are currently shown when a field is modified on the server but not on the client.
◦ X is rendered as deleted. All items under X are also rendered as deleted.
• One or more of the descendants of X were modified on the server.
◦ A delete conflict is displayed on X. The information message notifies you of modifications to descendants and asks you to review the modifications on marked descendants.
◦ A delete conflict is displayed on each modified descendant. The information message notifies you of the modification and asks you to review field modifications for that item. The item is annotated with an exclamation point (!) in the item.
◦ X is rendered as deleted. All items under X are also rendered as deleted, including modified descendents.
| Deletes on the server are different from deletes on the client. The above scenarios describe deletes on the client. For deletes on the server, errors are shown in the resynchronize banner. For more information, see Troubleshooting During Multiple-Row Editing. |
