-
-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEATURE: Integrate conflict resolution with publish/discard dialog workflow #3769
FEATURE: Integrate conflict resolution with publish/discard dialog workflow #3769
Conversation
2b55b57
to
3069277
Compare
5ae58ec
to
8e4a03d
Compare
3069277
to
f3ac501
Compare
926004b
to
1d493ed
Compare
Id like to help reviewing this so we can soon make the changes Neos requires regarding the rename an removal of |
@mhsdesign Don't worry about conflicts - I'll take care of keeping this PR up-to-date. So, unless anything upstream of the UI needs this change to move on, I'd say that everything else has more priority. |
2a29d84
to
fca73dd
Compare
50561af
to
faee8ca
Compare
@pKallert neos-ui/Classes/Application/PublishChangesInDocument/PublishChangesInDocumentCommandHandler.php Lines 62 to 74 in faee8ca
Does that match your intend? @mhsdesign So, same question goes to you as well :) |
Yes looks perfect thanks for taking care :) |
This moves the classes `ConflictsOccurred`, `Conflict`, `Conflicts`, `ConflictsBuilder`, `ReasonForConflict`, `TypeOfChange` and `IconLabel` into the `Application\Shared` namespace and adjusts all references accordingly. These classes are going to be reused by multiple command handlers.
This includes the following tasks; - Move `PublishChangesInDocument` -> `PublishChangesInDocument\PublishChangesInDocumentCommand` - Create `PublishChangesInDocumentCommandHandler` - Move `PublishChangesInSite` -> `PublishChangesInSite\PublishChangesInSiteCommand` - Create `PublishChangesInSiteCommandHandler`
…dedicated Factory
It may happen that `fetchAdditionalNodeMetadata` adds metadata for a node that has since been removed from the store. The occurance of such "zombie" nodes leads to problems, because they may lack crucial properties like `children` that are treated as always- present by other mechanisms throughout the UI. This became apparent after #3756. The CR.Nodes.MERGE action now takes care of preventing zombie nodes from entering the store.
This is to prevent the flakiness described in #3785.
This adds an e2e test case for cancelling and reselecting a resolution strategy and another e2e test case for immediate resolution cancellation. Both test cases are fixed by changes to the syncing saga.
…t" removes the document This also adds two more E2E test cases for publishing with automatic syncing.
faee8ca
to
f2526fd
Compare
Hi i kindof forget about this ^^ Would this be something for the next beta to include? And while navigating the code i found that this file is no longer in use |
…ution-03/rebase-during-publish
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There where some changes in the e2e setup and the test dont pass all on 9.0 anymore but that might be fixed here as well. But i still happen to get publish errors when running the tests locally: And the tests fail at a later point because we just click the Discard
button with the id #neos-DiscardDialog-Acknowledg
even if its an error:
The syncing tests are flaky and create catchup errors rendering following tests also kaput: #3769 (review) thus they will be skipped for now. Also we click the `button` in chrome and not the `a` as the > The action target (<a href="/neos/switch/to/neos-test-twodimensions-4">...</a>) is too small to be visible: 284px x 40px.
…ution-03/rebase-during-publish
That rebasing doesnt work is actually a core bug and will be resolved via: neos/neos-development-collection#5301 ... that fixes most of the tests locally but one is still failing ... |
…rror Currently, the `#neos-PublishDialog-Acknowledge` id will be used both for the "ok" button in success, and for the "cancel" button in case of any unexpected errors. To make the e2e tests fail fast we change the id in the error case to `Acknowledge-Error` so we dont accidentally click it. see also: #3769 (review)
…at failed instead we can just generate a uuid as the `sequenceNumber` was also unique for each command that failed see neos/neos-development-collection#5301 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much ❤️ tested in combination with the new publishing v3 everything works again locally: neos/neos-development-collection#5301
(I solved conflicts with 9.0 and also pushed a few minor changes)
…ution-03/rebase-during-publish
Peek.2024-05-29.13-09.Publish.+.Sync.mp4
solves: #3761
fixes: #3845
fixes: #3785
builds on: #3762
The Problem
With the introduction of conflict resolution, users can synchronize their workspace with recent changes in the base workspace by clicking the "sync"-button that is placed aside the publish dropdown. When a workspace is in
OUTDATED
state, the "sync"-button shows up.It may happen though that a workspace transitions into
OUTDATED
state without the UI taking notice of it. If the user then tries to publish their changes, publishing fails with an exception. Only after reloading the entire UI, they'll be able to trigger the "sync"-workflow.Steps to reproduce
Assuming you have two user accounts with
Neos.Neos:Editor
role (let's call them "editor-a" and "editor-b"):The solution
With this PR, the UI automatically triggers the sync and conflict resolution workflows if a publishing operation fails due to an outdated workspace.
Remaining TODOs
Conflicts
concept toApplication\Shared
namespaceConflictsOccurred
toApplication\Shared
namespaceConflict
toApplication\Shared
namespaceConflicts
toApplication\Shared
namespaceConflictsBuilder
toApplication\Shared
namespaceReasonForConflict
toApplication\Shared
namespaceTypeOfChange
toApplication\Shared
namespaceIconLabel
toApplication\Shared
namespaceConflictsOccurred
PublishChangesInDocument
->PublishChangesInDocument\PublishChangesInDocumentCommand
PublishChangesInDocumentCommandHandler
PublishChangesInDocumentCommandHandler
throwsConflictsOccurred
PublishChangesInSite
->PublishChangesInSite\PublishChangesInSiteCommand
PublishChangesInSiteCommandHandler
PublishChangesInSiteCommandHandler
throwsConflictsOccurred
ConflictsOccurred
into a Result DTO rather than an exceptioncatch (WorkspaceRebaseFailed $e)
clausesPublish
sagaconflicts
case toPublishingResponse
PublishingState.CONFLICTS