Skip to content
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

BUGFIX: Fix workspace role assignment after migration, import and site creation #5283

Merged
merged 2 commits into from
Oct 11, 2024

Conversation

bwaidelich
Copy link
Member

With #5146 a basic workspace access control was implemented. With that, users won't have access to workspaces unless they have a role assigned.

This can be achieved via

./flow workspace:assignrole

This bugfix makes sure, that the default behavior (users with the role Neos.Neos:LivePublisher can collaborate on the live workspace) is automatically ensured when creating/importing a site.

Furthermore, the migration command has been fixed to add metadata & role assignments even if no workspace title was set:

./flow migrateevents:migrateWorkspaceMetadataToWorkspaceService

Related: #4726

…e creation

With #5146 a basic workspace access control was implemented. With that, users won't have access to workspaces unless they have a role assigned.

This can be achieved via

```shell
./flow workspace:assignrole
```

This bugfix makes sure, that the default behavior (users with the role `Neos.Neos:LivePublisher` can collaborate on the `live` workspace) is automatically ensured when creating/importing a site.

Furthermore, the migration command has been fixed to add metadata & role assignments even if no workspace title was set:

```shell
./flow migrateevents:migrateWorkspaceMetadataToWorkspaceService
```

Related: #4726
Comment on lines +122 to +123
$this->outputLine('Assigning live workspace role');
$this->workspaceService->assignWorkspaceRole($contentRepositoryId, WorkspaceName::forLive(), WorkspaceRoleAssignment::createForGroup('Neos.Neos:LivePublisher', WorkspaceRole::COLLABORATOR));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo as hotfix we also should create a site entity for each imported site node here :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take care of that in a follow-up

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also thie needs to be try catched, as a workspace role might already be assigned if you run this import before and then run cr:prune as the pruning would not prune the assignments ...

Copy link
Contributor

@pKallert pKallert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested it locally and the live workspace shows up again 👍
Site creation in UI and console with site:create stopped working for me with this PR, even after flushing all caches, this should be checked before merging

@bwaidelich bwaidelich merged commit 321e171 into 9.0 Oct 11, 2024
10 checks passed
@bwaidelich bwaidelich deleted the bugfix/4726-fix-workspace-event-migration branch October 11, 2024 13:44
Comment on lines -516 to -519
if (!isset($eventData['workspaceTitle'])) {
// without the field it's not a legacy workspace creation event
continue 2;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without this statement

'Found %d legacy workspace events resulting in %d workspaces.

is wrong. .. also this is okay not to be there? We have runtime migration fallback? Why did we remove this check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants