Modeling roles for access control
Role enforcement will be done via policies. Is it better to add each role to a User as a property or should I create a Role resource and add a relationship between User and Role? Seems like having a separate Role relationship would make pick screens easier; otherwise I'd probably be hard-coding them.
1 Reply
Personally, I use an Enum type:
I use it as an array and also added an
active
field to disable users while keeping their record (auditing for ERP):
I also made some custom checks to facilitate policies and roles:
There are lots of pros/cons with this setup, but it's worked well for my particular scenario and is quite performant since all the data is right on the user resource.
Using the helpers to get the enum value is good for refactoring and avoiding typos in policies.
Oh, and the array of enums works out of the box w/ a Phoenix or Surface multiple select, and the enum helpers provide the options as well.
I use capitals and underscores as spaces in my enum names. This is compatible with GraphQL, and allows to easily humanize them: