chore: Don't set development permissions if they already exist

[teneightfive]

Proposed changes

What changed

Only set development permissions if they don't exist.

Why did it change

This prevents the permissions being overridden on every request.

It also means that they can be updated via another method like session
injection and won't be overridden.

[merlinc]

It also means that they can be updated via another method like session
injection and won't be overridden.

I'm a big fan of this concept!

So, to be clear in my mind, I've got a couple of questions that I've answered - can you confirm that I've got this all correct.

• How does changing of user permissions happen at the moment?
  • Users have roles returned as part of the auth process, these are then matched up with hard coded lists of permissions. We do not have "per user" changes to these permissions.
• Does this introduce any changes to the current process
  • No, because to currently change user permissions, we could need to change code and redeploy anyway

[teneightfive]

• How does changing of user permissions happen at the moment?

  • Users have roles returned as part of the auth process, these are then matched up with hard coded lists of permissions. We do not have "per user" changes to these permissions.

Currently, the only way permissions are updated for a user is by them signing out (therefore killing their session) and singing back in again.

On sign in, we get their role from the auth service and we match that to our permissions definitions. This is essentially the map between what particular roles can do within our application.

Application permissions are much more fine grained and it allows us to chop and change those between roles as we need to.

This change will hopefully also open up some progress on #804 and #807.

• Does this introduce any changes to the current process

  • No, because to currently change user permissions, we could need to change code and redeploy anyway

Nope, this module isn't actually loaded in production and is only used for local development.

But this current structure prevents any form of updating of these permissions dynamically (during development or tests) so this fix opens that up too.

Here's a WIP branch I have to show a way we can do this during development: https://github.com/ministryofjustice/hmpps-book-secure-move-frontend/compare/development/update-permissions

[codeclimate]

Code Climate has analyzed commit 7423a1f and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (90% is the threshold).

This pull request will bring the total coverage in the repository to 98.0% (0.0% change).

View more on Code Climate.