Access rights in masking fields of environment constants
When devs (or any other role) have access rights to change environment constants they are able to toggle the 'mask’ field option. This makes the field not readable for the users that browse through these constants. They however are able to deselect this 'mask’ option and read the value in this field even though it could contain sensitive company information (e.g. API-Key, Passwords, etc). We would like to have a separate authorization/permission to toggle this 'mask’ option per environment variable so that these values are not directly readable to anyone that have access rights to adjust the constants of this environment.
A solution could be that only Scrum Masters (or any other role) can only change the mask boolean yes to no and vice versa, or that there would be a separate permission to change the mask option of these constants.
@boris as a workaround for immutable constants you can create a microflow that returns a static string. You can then call this microflow in other microflows and use the return value as variable.
granted this does not work for all situations actual mendix constants can be referred today.
the idea of hiding/masking the value is to prevent eavesdropping. The current permission model is indeed very limited when it comes to managing access to different areas and capabilities of the developer portal. Would be nice to see this overhauled.
This is just another hint:
- constants changed in code, don't change when deployed a 2nd time. E.g. you have constant x = 1 and this gets deployed, you change code x=2 and deploy it again. Environment remains as x=1, this is frustrating because something that changed in code should have changed once deployed (it's common sense)
- constants act as environment variables, not as constants. Couldn't there be a way of making a constant hidden? so that nobody can change their values once deployed? so that constant can remain constant?
Looks like a valid idea to me. It could also be used to limit changing such a toggle only to a technical user (eg. which runs the CI/CD pipeline) rather than a personal user account like a scrummaster, in case of deployments to PROD environments.