RFC: Configure the visibility of inspector elements according to user roles

Hey there,

In one of our projects, we have defined an Editor role with very limited rights. These editors are only able to edit specific properties of specific node types. The inspector shows these fields nevertheless, so the editor gets an exception if he changes one of that fields.
Furthermore specific tabs, groups and views should not be displayed at all for such users - eg. the NodeInfo, which needs explanation.

It would be great, to have the visibility of properties, groups, views and tabs configurable according to the roles a backend user has.

I would like to get some feedback, on if you also have this requirements and if it would be a desirable core feature.

There is already a small package implementing that feature: https://github.com/punktDe/inspectorvisibility

Especially I would like to hear your opinions on the following considerations / implementation details:

  • The package uses Policies to configure the visibility. I didn’t like this approach at first, because hiding elements is not a security feature. But while trying to configure that separately, I ended up reimplementing the Policy framework completely.
  • The package overwrites the configured “hidden” property, if a policy matches. If no policy matches, the configured value should not be changed. For this I need to expose the PrivilegePermissionResult to check if it only contains Abstains.

Hi, Daniel!

Perhaps I don’t get something, but why isn’t it a security feature? If you are not allowed to edit something, you shouldn’t see it.
I think it should just be implemented in the core, the way we handle other policy restrictions already.

That sounds a bit hackish. Why just don’t do it at UI level?

1 Like

Absolutely. It’s on my wish-list for Neos. I never came up to post that wish somewhere, so thanks for that.

A definite must have since a long time!
There is not much use in restricting edit rights to a subset of properties if the user gets a form anyway and is slapped with an ugly error message if he tries to edit something. I would even go so far as to say: “EditNodePropertyPrivilege is not usable right now so lets implement that :-)”