Restrict Fields and tabs by Usergroups.

[thomashdk]

Umbraco version

v8

Description

We have some request about getting the "power" of restricting fields and tabs by usergroups.

Like this on for Umbraco 7
https://github.com/janvanhelvoort/Umbraco-hide-properties

Make it possible the select a usergroup, then a doctype and then select when fields or/and tabs should not be visible for that group.

How can you help?

I sort of all ready have done it in a light version..

The problem is that when ex. a user have all fields restrict besides the title field.
If the user fill out the title fields and published the node tha tall the other fields the user don't have access to will be emptied.

[nul800sebastiaan]

Thank @thomashdk, as a nerd I do feel like being able to tweak every little thing is fun, so this is very cool.

However, for Umbraco, it feels to me like this would be something that not many people would have a real need for.

Additionally, this would be a complex feature to implement, we know from experience with making granular permissions work that it's difficult to test for all combinations of permissions. Also, this would require a way to deal with concurrent updates (both your content editor and your SEO specialist make changes, overwriting each other's changes). This is of course already a problem we currently have, but at least you can use the rollback feature now if needed. When people don't have access to certain content, they should also not be able to roll back that content.

I'm sure there's more complexity, and we always aim to make complex things simpler in Umbraco, so we don't shy away from complex problems.

But let's talk about the need for this first, what do different scenario's look like for users?
And then let's also question the reason there are fields on a page that a content editor is not allowed to edit. They don't know about those fields, but I imagine that field content will show up somewhere on the frontend.. Will it be confusing? And most of all.. does that content really need to live on that node? I see Scripts an Settings. These seems like things that don't need to be stored on all content items, I would think about some separation of concerns there as well.

Anyway, sorry for rambling, just trying to get some thoughts out there to discuss this further.

[thomashdk]

Hey @nul800sebastiaan

Thanks! I follow what you are saying.

And make sense not to hide fields for the user that will confuse if there is content in the frontend that are showed but they can't changes.

The issue here is that we ex. have a switch on a node to boost a specific node in a search. That shouldn't be some a regular editor should have the "power" to do..

A lot of our client are based on the same baseline project and som fields are not relevant for all clients, so it would be nice to be able to hide does.

But I follow what you are saying :)

[nul800sebastiaan]

Obviously I know you've made your choices but to me it seems like something that's not directly editing the page, shouldn't really be on the node if you can get away with putting it somewhere else. Of course sometimes it's unavoidable and I've built some features before with eventhandlers resetting whatever a user of type "Editor" changed on some properties! 😅