Our organization uses Roles to segregate Projects from various business units. We will not be able to utilize properties for any sensitive information because this feature is not implemented. Plus, one Bus. unit doesn't need to see the props from another anyway because it just confuses things. We have to use naming conventions to separate them.
In general, it would help to hide passwords from whoever shouldn't be seeing them.
Send us a ticket, we will try our best to assist you with your problem
Jeffrey DaSilva
Ability to secure Properties and Lookup Tables at granular level by Role
The current ability to secure Properties and Lookup Tables is all-or-nothing by role. It would be great if more granular level security could be built around these two resources. This could be something simple like secured vs public properties/tables or maybe more complex by somehow securing specific properties/tables to specific roles.
Use Case: The bulk of our properties are configuration items that we would like expose to users to be able to update in our Production environment. Unfortunately, we are not able to do this because of a few sensitive properties that are being leveraged. We are currently not storing any sensitive data in Lookup Tables and currently have these exposed to everyone in Production so that they can update their configuration data that exists in these tables. We have cases coming up with teams/roles are looking to load sensitive data into the configuration but are not able to because this data would be available to all other roles that configure their use case via these tables.
5 people like this idea