Allow adding access Roles/Groups to items for security validation

On our radar
The idea is to simplify "hiding/inactivating" items on the screen according to security roles / groups in service studio. 
By default, everybody has access to the item, but you will be able add restrictions to them by adding this information just as you would Extended Properties.
You should be able to select the Role/Group and then indicate the action which would be one of the following:
- Hide (simply hides the element from the screen)
- Inactivate (the item is visible, but inactive)
- Encrypt (for text values, or editable information, it would show ***** if the user doesn't have access to that field)
An item should allow multiple of these properties.
Attached is a simplified mockup
Created on 4 Feb 2016
Comments (3)

How does 'hide' must be applied? Display: none? Because the security about that is that the html would still exist in the html.
What is the advantage for the encrypt? If I'm a user, what is the advantage of seeing something (****) I'm not allowed to see?

Think these are related to business wishes (show it/ don't show it, enabled/disabled etc) and therefor hard to apply.

With this I was more thinking of selecting which role can acces an element based on the role (the same as screens work, only then on elements in the screen). Disadvantage of that is that it would be hard to see why something isn't shown or working (in service studio the if statement wouldn't be used).

I like the idea as a concept. As Evert points out, too much of the implementation is business-specific. :(

Hi Evert,

I borrowed this idea from Microsoft Dynamics CRM, but there it's at a deeper level (on the record attribute itself) and not just the graphic HTML element. If this could be implemented on the "attribute" level of the entity, that would open up the doors to a whole new level of "information" access levels.

I understand the security issue, but (me still being a young padawan and learning) I was thinking the page would be served WITHOUT this element if the requesting user didn't have access to it. In other words, there would be some pre-processing on the server side to actually serve the HTML component or not.

Regarding the "encrypt", it may be useful for the element to be there just to keep the page formatting correct even if a user cannot see the data in one of the elements.