BUGFIX: Scope pending changes indicator to the current site

[robinroloff]

What I did

Fixes #4151 and #3923.

In a multi-site setup with a single content repository, WorkspaceService::getPublishableNodeInfo() returns all pending changes of the personal workspace, while "publish all" is scoped to the current site via WorkspacePublishingService::publishChangesInSite().

So editors working in site A see an orange publish indicator for changes that belong to site B, and publishing fails with:

The command "PublishIndividualNodesFromWorkspace" for workspace <user> must contain nodes to publish

getPublishableNodeInfo() now takes an optional SiteNodeName and skips changes whose closest site node does not match — mirroring the scope that is actually used for publishing. The four places that build the workspace info pass the current site:

Where	Source of the site
Configuration/Settings.yaml (initial state)	site.name from the Fusion context
AbstractChange::updateWorkspaceInfo()	closest site node of the changed node
BackendServiceController::getWorkspaceInfoAction()	SiteDetectionResult
BackendServiceController after changing the base workspace	closest site node of the document

All four matter: if any of them keeps counting workspace-wide, the indicator falls back to the wrong number as soon as that code path runs.

The parameter is optional and defaults to the previous behaviour, so other callers of this @internal API are unaffected.

How to verify it

In a multi-site setup with a single content repository:

1. Change something in site A, do not publish
2. Switch to site B → the indicator no longer shows the change from site A
3. Change something in site B → only that change is counted
4. Publish in site B → succeeds, the change in site A is untouched
5. Switch back to site A → the change shows up again and can be published

Also worth checking that the normal case still works: several documents changed within the same site are all counted and published together.

Notes

As @mhsdesign points out in #3923 and #4151, the change calculation is due for a rewrite (neos/neos-development-collection#5459). This is the pragmatic fix in the meantime — it makes the indicator agree with what publishing actually does, without touching the change projection.

The content repository side is neos/neos-development-collection#5975, which makes publishing an empty changeset a no-op instead of an exception. The two are independent: this PR stops the UI from offering unpublishable changes, that one stops the exception for any other caller.

One trade-off worth flagging: the filter does an additional findClosestNode() per pending change. On workspaces with many pending changes this makes building the initial state slightly more expensive.

[mhsdesign]

hi thank you for caring. We are aware of this bug and its primary cause is that the change projection and change handling is just a flat storage and without doing expensive queries for each entry during call time more or less needless.

As described in neos/neos-development-collection#5459 id rather like to build a proper solution. Currently a workspace with many changes takes already time to answer the question if a node is on the current document which is N+1 and now we add the complexity for the site question as well.

@dlubitz is working on making the queries actually performant but that is for Neos 9.3+ so id say this change should rather target that. What do you think? If we really need this for 9.0 we definitely need to find out how this impacts performance with workspaces with no, small and many changes - especially the UpdateWorkspaceInfor thing.

[VolkerLieber]

Hi @mhsdesign, this is currently a breaking bug for our customers, so it would be highly appreciated if this fix could be accepted before the 9.3+ version.