FEATURE: Hide read only workspaces

[markusguenther]

When you work with countless backend users and workspaces, it may happen that the restricted editors maybe are confused by all the available workspaces. And sometimes select a workspace that is read only. Then they can not edit content since the latest bug-fixes and before that, they run into an error while publishing.

This feature should enable the developers and integrators to hide all none writable workspaces in the selection. That should improve the user experience for the editors. By default, the setting is false and therefore everything is like before that feature.

When you enable it with the setting 
initialState.user.settings.hideReadOnlyWorkspaces the user will see only writable workspaces in the publishing dropdown, except there are no writable workspaces. Then we use the default target workspace as fallback. This is often live.

Resolves: #3012

[markusguenther]

This is a bit related to the former issue #2796

[markusguenther]

Thanks for the approval, any suggestions on naming things or did I forget anything?

[lorenzulrich]

Thanks @markusguenther for your work. There is one drawback we need to tackle.

Scenario:

• I create a user that has only permissions to read-only workspaces (a kind of RestrictedEditor) - in my example called "Freigabe KM"
• When they first open the backend, the status bar correctly shows that there are no changes and they are in this workspace:

• However, the base workspace of their user workspace is still live:

• So as soon as they start editing content, the changes are made based on the live workspace. As this one is no longer available, the publish button shows:

• Clicking it then obiously leads to an exception because we are not allowed to publish to live:

I can make it work if I rebase the account's user workspace to my read-only workspace after account creation. However, since we don't have a UI for that, this is not feasible.

[markusguenther]

Talked here with @lorenzulrich and as the UI uses the configured targetWorkspace the idea was to have a conditional target in the configuration. But need to test that of course.

[markusguenther]

Ok, tried to fix the latest issue @lorenzulrich mentioned and found out that also a regular restricted editors have the issue that the baseWorkspace can be wrong. So the initalState is with the first writeable Workspace, as I adjusted that, but this does not lead tothe fact that the user really has this workspace set as baseWorkspace.

The problem here is that I tried to detect that and then just change the baseWorkspace but the initialState is built with a GET Request, and we need a POST to be able to change the Workspace. So I am now at the point where I would say a dialog for the User would be nice. Something like "Your on a non writeable workspace, would you like to change to workspace foo" and when the user confirms that we change the workspace. Or would you say I search for a right place and just do it without confirmation by the user.

I mean, in the end, the user cannot do anything when he doesn't switch the workspace.
Is just confusing at the moment that the user think that he is right because the initalState returns the first writeable WS at the moment.

WDYT?

[markusguenther]

Ah also played a bit with the WorkspaceHelper and conditionally change the baseWorkspace on editing things. But that feels bit hacky because you need to take care that it is the right place, which is always from a POST.

Here was the Idea to adjust the Feedback/Operations/UpdateWorkspaceInfo.php and detect here that we are on the wrong baseWorkspace and change it. But as mentioned... it feels bit hacky

[lorenzulrich]

I think that a solution with a dialog would be nice. It is more transparent for the user than just switching it on-the-fly.

Let's have a look at a real-life example:

This is the Neos Documentation. How would the UI react here for me as a restricted user? Would I land in "Next release" without knowing? If so, I don't think that would be a good behaviour. I would then prefer something like:

[markusguenther]

Hope to get this polished this evening/night

[markusguenther]

I am ill since Yesterday, so i fear that i Will not male it today :/

Sorry...

[mhsdesign]

Maybe we can get this into 8.1?

[kdambekalns]

Too late for 8.1 by now, but what a nice feature it would be. 👍

[Sebobo]

Hi @markusguenther is this now ready for a final review?

[markusguenther]

I need to finish that ... the idea from @lorenzulrich is not implemented yet.

[mhsdesign]

uups sorry for closing this accidentally (fat finger on mobil^^)

---

and also sorry for this discussion in another direction:

i lately talked with @ahaeslich about this workspace selector and its position in the ui in general.
we found that it should not necessary be grouped inside of the publish menu
(i even had a hard time finding it the first time)

you proposed to cleanup the current implementation with an opt in feature flag

i think we should better strive for a nice default than extensive customization. So while the problem will be solved for those knowing the flag initialState.user.settings.hideReadOnlyWorkspaces it would be even greater to find a compromise for both usecases.

my idea is having a workspace select dropdown next to the publish menu (like the user settings select box)
and each entry in the list indicates via icon or text or color, if its an readonly workspace.
that should solve the issue too right?

if youre wondering why im focusing here on the separately placed dropdown - i just think that otherwise things get too crowded

moved to: #3247

[Sebobo]

@markusguenther do you want to finish this for 8.2?

[mhsdesign]

@markusguenther would you like to discuss with me #3011 (comment) ?

[kdambekalns]

My vote for allowing read-only workspaces to be selected, but making it clear they are read-only. Even a read-only workspace might one day become usable for copy/paste (see #3244 (comment)), and then it would need to be selectable.

Also it can be very confusing to not see a workspace you know does exist…

[Sebobo]

My vote for allowing read-only workspaces to be selected, but making it clear they are read-only. Even a read-only workspace might one day become usable for copy/paste (see #3244 (comment)), and then it would need to be selectable.

Also it can be very confusing to not see a workspace you know does exist…

As it's a new setting and disabled by default I think it's fine the way it is?
I wouldn't like to have it as default. Therefore when it's enabled in a project the editors can be briefed.

Or we could add a note like "9 read-only workspaces are hidden" at the bottom. But not sure if that is helpful...

[mhsdesign]

As it's a new setting and disabled by default I think it's fine the way it is? I wouldn't like to have it as default. Therefore when it's enabled in a project the editors can be briefed.

i dont think an editor needs to be briefed if next to a workspace appears the text or badge (read only) with a lock icon.
Seems pretty self explanatory aand editor friendly - and as suggested by @kdambekalns it would change anything, as the workspace is still selectable.

[Sebobo]

Seems pretty self explanatory aand editor friendly - and as suggested by @kdambekalns it would change anything, as the workspace is still selectable.

One of the problem this feature solves is that there are projects with dozens of workspaces and most of them might be irrelevant/read-only for the user + role. So hiding them makes it easier for them to find the ones they work with. That's also what Markus describes in the PR description.

[mhsdesign]

One of the problem this feature solves is that there are projects with dozens of workspaces and most of them might be irrelevant/read-only for the user + role. So hiding them makes it easier for them to find the ones they work with. That's also what Markus describes in the PR description.

thanks for explaining that. I hadn’t this in mind but this seems like a valid usecase.

I still oppose to the yaml feature flag, but what about a checkbox in the workspace selector someplace to hide and unhinde readonly workspaces (enabled by default)

(In case things get too crowded I would prefer the workspace selector in another position (next to the publishing menu) either way)

[markusguenther]

Will not find the time to finish it this time. So a new feature for 9.0 🙈

[markusguenther]

Seems it needs more love for 9.0 💙

[markusguenther]

Rebased it to version 8.4 and now just need to finish it 🙈