solves: #3744
builds on: #3759

Description

When editors work in parallel, it may happen that one editor publishes changes that create conflicts with the changes of another editor. Since #3665 it has been possible for users update their workspace whenever it has fallen out-of-sync with its respective base workspace. Up until now, this mechanism doesn't handle conflicts. When a rebase operation fails due to conflicts, users are trapped in a workspace that cannot be synced, published nor discarded. The only way out is the CLI (see: neos/neos-development-collection#4939).

TLDR; This PR introduces a dialog workflow that allows users to select a resolution strategy for dealing with conflicts that arise during the synchronization of their user workspace.

How to provoke a conflict

Assuming you have two user accounts with Neos.Neos:Editor role (let's call them "editor-a" and "editor-b"):

1. Log in as "editor-a"
2. Create a document "Test"
3. Add a text node to "Test"
4. Publish those changes
5. Edit the text node, without publishing that change
6. Log in as "editor-b" in a private window

• You should see the orange "Sync" button now

7. Sync "editor-b"'s workspace, so you can see document "Test"

• This should trigger the synchronization workflow without conflicts

8. Remove document "Test"
9. Publish that change
10. Switch to "editor-a"'s window and reload

• You should see the orange "Sync" button now

11. Edit the text in the text node on document "Test"
12. Try now to sync "editor-a"'s workspace

• This should trigger the synchronization workflow with conflicts

Conflict-Free Synchronization Workflow

When the user clicks on the orange "Sync" button, a dialog opens that asks them to confirm their intended action. Once they click "Yes, synchronize now", a process indicator opens that cannot be closed. During the operation a beforeunload handler prevents the user from leaving the page. After the operation has finished, the user is presented with a dialog stating the success of the synchronization. Once they click "OK", they see the updated UI state.

If synchronization has removed the document that the user was currently looking at, they have been silently redirected to the closest ancestor of that document.

Synchronization with Conflicts (Strategy FORCE)

Again, when the user clicks on the orange "Sync" button, a dialog opens that asks them to confirm their intended action. Once they click "Yes, synchronize now", a process indicator opens that cannot be closed. If the server-side rebase operation fails, the process indicator is interrupted by a dialog that states the presence of conflicts and offers a choice between two strategies to resolve those conflicts:

1. Drop conflicting changes
2. Discard workspace "workspace-name"

If they choose "Drop conflicting changes" as a resolution strategy, the user is again presented with a dialog that asks them to confirm their intended action. Once they click "Yes, drop those changes", the synchronization starts once again, this time transmitting force: true to the server-side command handler.

The rest of the workflow is analogous to the Conflict-Free Synchronization Workflow.

Conflict List

The conflict list is shown both in the "Resolution Strategy Selection"-dialog and the "Confirm: Drop conflicting changes"-Dialog. Conflicts are calculated from a list of CommandThatFailedDuringRebase-model objects, that carry information about the attempted CR-level command and the exception that prevented this command from being applied.

The conflict list is a vertical list of <detail>-elements with a <summary> consisting of an annotated node type icon and the label of the affected node. The little orange annotation to the node type icon represents the type of change, which can be one of 4 things:

1. The node has been created
2. The node has been changed
3. The node has been moved
4. The node has been deleted

The list of conflicts has been squashed on the server-side, so only one (the very first) change per node aggregate will be displayed.

Conflict Details

Opening any item in the conflict list will show the user details about that particular conflict. They will once again see what happened to the affected node in their workspace, and then what is the reason that prevents that change from being applied. Additionally, they'll see what document and what site the affected node belongs to (because conflicts don't necessarily pertain to the site the user is currently looking at).

The "reason for conflict" info is a best-effort guess from the exception that had prevented the respective command from being applied. At the moment, the only reason that will be displayed is "[Node] or one of its ancestor nodes has been deleted". It is possible however for this field to remain empty. Over time we can add more scenarios to the server-side handling of conflicts to better describe each situation.

Synchronization with Conflicts (Strategy DISCARD_ALL)

Once again, when the user clicks on the orange "Sync" button, a dialog opens that asks them to confirm their intended action. After they click "Yes, synchronize now", a process indicator opens that cannot be closed. Upon failure of the server-side rebase operation, they are presented with a "Resolution Strategy Selection" dialog.

If they choose "Discard workspace ..." as a resolution strategy, the user is again presented with a dialog that asks them to confirm their intended action. When they click "Yes, discard", their entire workspace will be discarded.

The synchronization process is resumed afterwards.

Error Handling

Errors are handled just like in #3759.

Remaining TODOs

• Convert WorkspaceSync container to typescript
• Convert SyncWorkspaceDialog container to typescript
• Create sub-dialogs for conflict resolution workflow
  • Split out ConfirmationDialog
  • Dialog for resolution strategy selection
  • Confirmation dialog for "Discard All"
  • Confirmation dialog for "Save what you can" a.k.a. "Force Rebase"
  • Result Dialog
  • Process Indicator
• Move UI.SyncWorkspaceModal redux state to CR.Syncing
• Wire up new dialogs with CR.Syncing state
• Implement DISCARD_ALL strategy through integration with existing Publish/Discard workflow
• Reload Document Tree and Content Canvas after successful rebase
• Add beforeunload handler during rebase
• Fix: Warning: Failed prop type: Invalid prop focusedValue of type number supplied to SelectBox_ListPreviewFlat
• Fix: Warning: Each child in a list should have a unique "key" prop. Check the render method of ConflictList.
• Fix: Could not find icon { prefix: "fas", iconName: "questionmark" }
• Squash similar conflicts into one to reduce visual redundancy
• Add E2E test scenario that creates a conflict state between two editors and asserts the results of choosing "Discard all" as a resolution strategy during rebase
• Add E2E test scenario that creates a conflict state between two editors and asserts the results of choosing "Save what you can" as a resolution strategy during rebase
• Remove legacy WorkspaceStatus.OUTDATED_CONFLICT from ts-interfaces
• Remove legacy state.ui.remote.isSyncing
• Remove legacy i18n labels
  • Neos.Neos.Ui:Main:workspaceSynchronizationApplied
  • Neos.Neos.Ui:Main:syncPersonalWorkSpaceConfirm
  • Neos.Neos.Ui:Main:syncPersonalWorkSpaceMessage
  • Neos.Neos.Ui:Main:syncPersonalWorkSpaceMessageOutdated
  • Neos.Neos.Ui:Main:syncPersonalWorkSpaceMessageOutdatedConflict
• Fix: All 0 change(s) in workspace "user-admin" were sucessfully discarded.