Way to limit edit access of an attribute to a specific Role?

Forum|Forum|4 years ago
September 1, 2021
5 replies
2885 views

Is there a way to limit edit access of an attribute to a specific role?

We're considering adding a new attribute on our WTParts, but only certain authorized users should be able to modify this attribute. Is that possible?

The next best way I can think of to manage it would be to have a document subtype that only the authorized users could create and edit, and then they could link that to the WTPart. Is there another way to achieve this kind of data control?

Bus_System Administration

Best answer by d_graham

Joe,

Doable for sure. This can be done with a listener.

It would require some code but nothing fancy.

I had a request to validate four attributes based on the folder the object was in, the group the user was in, and a few other criteria.

You could certainly do the same thing based on the user's Team role.

If the modifying user is in the approve to modify that attribute role, do nothing.

If the user is not in the role throw and exception. This will stop the modification.

If that's of interest I'll explain further.

BTW, porting this to the target system during an upgrade is simple.

David

A

Ajit_Kulkarni

16-Pearl

Hello Joe,

So the datautility will do the job for you. In utility , you can detect the mode and user (participant). From participant you could figure out its role and logic to enable or disable the attribute.

Its tedious way, not as simple as profile. However definitely achievable.

Regards

Ajit

D

d_graham

Answer

18-Opal

Joe,

Doable for sure. This can be done with a listener.

It would require some code but nothing fancy.

I had a request to validate four attributes based on the folder the object was in, the group the user was in, and a few other criteria.

You could certainly do the same thing based on the user's Team role.

If the modifying user is in the approve to modify that attribute role, do nothing.

If the user is not in the role throw and exception. This will stop the modification.

If that's of interest I'll explain further.

BTW, porting this to the target system during an upgrade is simple.

David

joe_morton

Author

18-Opal

Hi David,

Thanks for your response. We've had listeners externally developed for us in the past, but it's a little beyond our internal skill set at the moment. We have some training scheduled, and this very well might be our first project.

Thanks again!