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]

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 🙈

[markusguenther]

@mhsdesign @Sebobo Short question - how we handle PRs like that. As that would be upmerged to 9.0 it could not work out as 9.0 cannot get a new feature. So the decision to release 8.4 after 9.0 is not the best idea for the upmerge concept.

[kdambekalns]

Well, when upmerging the question rather is – do we want or need this feature/bugfix. If no, because it does exist already or no longer applies for other reasons, "skip it". If not, adjust it or at least open a ticket to keep a note on "the missing thing" for 9.0.

Granted, skipping a feature or bugfix when upmerging might be heard, but it should not be a blocker. If it turns out to be too hard, we can still cherry-pick things and then could even do "an empty merge" to signify things have been taken care of.

[Sebobo]

Hm, I assume that projects that go to 8.4 don't upgrade to 9.0. So we could also skip it in the upmerge and add it to 9.1.
It's not the only feature that is currently waiting for a merge into 8.4 and that strategy could be applied for more of them.
Not sure if that causes more problems than it solves though :D

[markusguenther]

Thanks for the input! Would be great to have the opportunity to introduce features, even if it means being a bit more careful during upmerges. Skipping something can definitely lead to issues if we’re not paying close attention.

[mhsdesign]

Im against sneaking new features like these or other during an upmerge and have them unintentionally pop up in 9.0.x (some patch). Though we can super simple make an empty merge. That can be done without any issues if 9.0 already contains the latest 8.4 up-merge, then merge this in 8.4 and just discard ALL changes inside the upmerge ... not just the conflicting ones!!!.
Neos 9 already does not have full feature parity with 8.3. We should just need to keep track of all the things that are different. Also if we ever reimplement these features for 9.x the git history will be a bit funny but :D
Some features with this 8.4 problem may also be considered bugfixes so they could be targeted 8.3 and come directly into 9.0.