Prod permissions audit functionality - Mendix Forum

Prod permissions audit functionality



As someone that manages a small team and has to give and then revoke production access so that developers only have access for the duration of their deployments, it's a bit tedious managing the requests.


The current process for myself looks something like this:


If asked I will need to be able to provide the list of requests which will be me going through the emails.


It would be much easier, if, when I go to change the prod permissions for a developer, I was greeted with a popup box with a reason as to why it is being changed. It would also be very beneficial to have the audit of the requests within Sprintr itself.


There is already some functionality in the audit of the environment that shows changes made and by who. But it would be nice if this permissions piece was separate from that so it could be exported.

4 answers

Got it, thanks for that explanation it helps me understand your process and how we can improve your experience. 



I can grant permissions ahead of time to allow the developer to do the deployment in the evening. I can then remove the following morning. This takes about a minute to do both.


All our deployments are scheduled for around 90 minutes so that the deployment happens, which may or may not require configuration and changes we need to make, and then allow the PO to do testing. We then have to close change requests as part of the governance process here. Hence the 90 minute window.


I don't need to be online for that time and the developer can do it all on their own. The developer involved in the change is also best suited to make those necessary changes.


So it's either I spend 30 seconds giving the rights ahead of time and a following 30 the next morning when I logon to remove or I do every deployment, am required to spend up to 90 mins on each, multiple times a week, with handover documents. Or, it takes me and the developer who worked on the change to be online together and I do the changes on their behalf. Neither are a great solution.





Hi Richard,

I understand that when you scale up you get more admin tasks, but you state that every time someone needs to deploy something, you need to adjust the permissions: grant them and then take them away again? 

Or did I misunderstand that?

I thought granting and removing permissions was more or less the same effort as deploying a package?




Thanks for taking it into consideration.


As for this:

As for your current workflow: is there a reason why you don't just execute the deploy to production yourself? Would save you having to grant people those permissions?


We currently have 25 applications, with a new one always in the pipeline. It's a tall ask for myself to manage every single new app deployment and every breakfix.


As we have to do all deployments outside of core business hours and I would say on average we have 3 deployments a week. That's a lot of my time, or any other single person solely responsible for deployments to take on.