Configure wich entity attributes are shown by role

Configure wich entity attributes are shown by role

  
Hi.

Is there any way to make configurable by role the visibility of entity attributes?
What was intended was to have a page where the administrator could choose the attributes that users with a particular role can see. This question arises because the application is subject of many changes in this sense, and was intended to prevent the publication of espaces every time that a new restriction appears.

Thanks in advance.
Hi Patricia,

If you think of entity attributes as corresponding to DB table columns (which is what they are), I don't see how hiding them globally depending on the user would make sense.

Do you maybe mean hiding inputs in a form corresponding to an attribute so that a certain user won't be able to enter them?

Let me know,


Miguel
Miguel Melo wrote:
Hi Patricia,

If you think of entity attributes as corresponding to DB table columns (which is what they are), I don't see how hiding them globally depending on the user would make sense.

Do you maybe mean hiding inputs in a form corresponding to an attribute so that a certain user won't be able to enter them?

Let me know,


Miguel
 
 Yes that's it. But I need it to be configurable in a administration page.
Patrícia Lopes wrote:
 
 Yes that's it. But I need it to be configurable in a administration page.
 
 Hi Patricia.

Why would you want to do that?
I know the pungency of my question and it is not innocent. Believe me I've followed that path way too many times.
If you implement an administration page to manage permissions at such a level you're buying a big problem. Let me try to give you a comparison matrix.

  Implement the logic in
Service Studio
Have a backoffice to
configure a rules engine
Implementation Wrap input with if with logic to show or not the input.
Address security based on user roles instead of such a granular fashion. It is easy to come back to Service Studio and change it afterwards.
Wrap input with if with logic to show or not the input.
Backoffice page to configure rule.
Think thouroughly if you're addressing security in a much too granular way.
Testing Fixed number of test cases. Developer can perform the tests. Undetermined number of test cases; depends on configuration in backoffice. Developers can't really test everything.
You may need to implement a sandbox for the users, meaning that they'll want to test their configuration before making it "active".
Staging Configuration is published along with code Configuration needs to be migrated between environment or recreated. This means extra development effort.
Knowledge Transfer Everything is in the code making it more easy to do maintenance and evolution of that code Much harder for a new comer to understand the logic and the application


If you're having trouble convincing your customer that you're going the wrong direction see if you addressed each point of this matrix with him.

I hope this helps you out.

Cheers,
André
Ok thank you.

I said from the beginning that it was probably not possible but I thought I'd try since it is a component that is constantly changing in this regard.
@Patricia you're welcomed.

Just to make it clear I didn't say it wasn't possible, it is just not out-of-the-box and such approach carries on many risks and also other collateral developments that you don't normaly need. The matrix is only to help assess if you're on the right track, if the investment pays off and the risk is mitigated...

Cheers,
André