RestrictedEditor with restricted workspaces and restricted document tree area causes errors

[Benjamin-K]

Setup

Create a role with the following settings:

• Non-Abstract Role
• Parent roles: RestrictedEditor
• Permissions: View & Edit & Create & Delete
• Select nodes
  • ... in workspace: Select multiple workspaces
  • ... in dimensions: Leave blank
  • ... in document tree: Select a subtree

Behaviour

• The user can view all pages (which is fine)
• The user sees blue area / can edit pages he has access to.
  • Problem 1: This applies also to workspaces he should not have access to change nodes
  • Problem 2: An error is shown after editing some content. The error is not always displayed on the first change, so even when the user is in the wrong workspace (applies to the correct workspace(s) too), he can edit nodes (partially) until the following error is shown:

    Access denied for method Method: Neos\ContentRepository\Domain\Model\Node::setProperty() Evaluated following 1 privilege target(s): "Sandstorm.NeosAcl:EditAllNodes": ABSTAIN (0 granted, 0 denied, 1 abstained) Authenticated roles: Neos.Flow:Everybody, Neos.Flow:AuthenticatedUser, Dynamic:Presse, Neos.Neos:RestrictedEditor, Neos.Neos:AbstractEditor, Neos.ContentRepository:Administrator, Neos.ContentRepository:InternalWorkspaceAccess

When removing the workspace restriction, all works out pretty well.

[markusguenther]

I also have an error without Dimension and Workspace Restrictions.

https://user-images.githubusercontent.com/1014126/201325464-527ea4bb-8821-4d5f-8c39-1dc89af88b96.mp4

[Benjamin-K]

Part of the problem will be solved when Issue neos/neos#3893 will be merged.

[bwaidelich]

We have come across the same issue: Restricting the Workspace and subtrees does not seem to work (@markusguenther I think your issue is not related though, that looks more like an outdated session)

@skurfuerst can you think of a solution without AOP? We rely on this in a project and I think that there are funds available for commissioning a fix

[Benjamin-K]

I think the issue needs to be fixed in the Core. IMO the current implementation of the isInWorkspace privilege matcher makes little to no sense. It will only apply if the current user or any other user already made some changes in the current workspace. But it should actually only match, if the currently selected workspace of the user is in one of the defined workspaces.

Which again leads us to neos/neos#3893. We can also discuss this issue there and i can also create a PR, but i waited for some more responses as changing the existing isInWorkspace implementation would be breaking.

[bwaidelich]

@Benjamin-K Thanks for your input. Yes, let's discuss the issue in https://github.com/neos/neos-development-collection/issues/3893 <3