Open mhsdesign opened 1 year ago
Looking into #4588 and Sebobo/Shel.Neos.WorkspaceModule#33 I also found that creating a new workspace based on the title will lead to workspace names like "My funny workspace-p54t2". Is this expected as this is differes to the pre neos 9 behaviour?
i think the auto suffix only happens with sebs workspace module and not via cli and the legacy module.
As discussed today:
Maybe we can move the whole Workspace ownership topic out of the CR to Neos.
The simplest way to do so would be a property in the User
model that refers to the user's workspace name, but probably it would make sense to directly add a proper relation AccountIdentifier
to n owned/accessible workspace names per CR ID.
That way we could make sure to only ever create workspaces that have not been used yet and can still always resolve the owner from the workspace name vice versa. It would also greatly simplify the Neos implementation for our "Privilege Provider" because we can simply match the workspace name with that relation table...
Since users may have multiple accounts (e.g. one per authentication provider), personal workspace names should refer to user IDs and not workspace IDs. This would also solve the \Neos\Flow\Security\Account::setAccountIdentifier
oddity as user IDs can never change.
Or we assume (and thus must also enforce) that all accounts for a user must have the same id
Currently, we always use the security context account's id, except when comparing for accessibility in Neos.UI's WorkspaceService::getAllowedTargetWorkspaces
I agree but turning workspace names into cryptic UUIDs could pose new issues regarding readability and "debuggability". What do you think of this idea:
Workspace
model back to Neos (maybe even integrate it to the highlevel Workspace API we introduced with #4943)With that we could do something like:
// naming tbd of course
$this->someWorkspaceService->getDefaultPrivateWorkspace($neosUserId)->publishAllChanges();
The names of those workspaces could still be "human readable" with that, but more importantly they would be wired to a Neos user with an explicit mechanism
Yes please! Clear realation between user and workspace would be great
I also noticed that getAllowedTargetWorkspaces
in the Neos ui is partly wrong / dead code:
workspaceOwner
is an id but not the instance thus it must be:
$userIdentifier = $this->persistenceManager->getIdentifierByObject($user);
if ($workspace->workspaceOwner !== $userIdentifier) {
continue;
}
This will be addressed with the security issues
While working on #4534 we found this logic
https://github.com/neos/neos-development-collection/blob/033c07ab1d999dc3edca93a8d58259e95514ad13/Neos.Neos/Classes/Service/EditorContentStreamZookeeper.php#L121-L126
As discussed in slack and here we came to the conclusion that this
increment
logic will never be executed.To reassure this i placed a logger at this point and tried a few scenarios. I couldnt prove our thesis wrong but i noticed other oddities that we need to address.
Foo
has a personal workspace nameduser-Foo
. If the user is deleted and a new user namedFoo
is created it will use the previously still existent workspaceuser-Foo
.\Neos\Flow\Security\Account::setAccountIdentifier
and that would break the coupling of user <-> workspaceuser-Lol
and a new userLol
would use it as personal workspace.user-Bar-p54t2
(which will then not show up in the list be cause they are "user" workspaces)WorkspaceProvider
should have aprovideForUser
factory