Usually it's easier to attach permissions to roles than to users, because then your permissions_users table would explode in size (every new user has to have all its default permissions copied in the system).
It also makes it harder to add new permissions, because you have to create a row for each user in the system.
So, let's say that tomorrow I introduce a new resource in the system, with a set of default CRUD permissions, what happens to the users? Can they work on that resource by default or do I have to create 4 permissions multiplied by the number of users in the systems?
What if I want to change the read permission for all the users with a role X? In your schema I have to go to the DB, load all the users with that role, and edit their corresponding read permission.
If instead roles are attached to permissions I can just edit one line :-)
Another approach I like it's Pundit's, in which permissions are inside the business logic, because they might be granted only if the user passes a complex test. Let's say for example that you want to grant access to a resource only if a user was created in a date range and if they have 5 points accrued in your system.
By having permissions written in stone in a table you might have to modify them at runtime by calculating if the user passes the test, then add the specific permission and then let the user pass through. But what happens if the users the day after don't have the 5 points anymore? You are allowing them through even if they shouldn't be allowed. Yes, you could setup a callback for each time they lose a point but... well you know, it's going to explode pretty soon in complexity.
If, instead, permission are part of the business logic, you can easily test them in isolation and have them as complicated as you wish, without relying on a "switch table".
Hope this offers you a possible alternative in case you have a more than trivial setup. Let me know if there's something that's not super clear!
I really don't have much to add, your approach is much flexible and clearer. I actually wrote a couple sentences how I used permission_users for "one-off" permissions, but then I deleted it after realizing you've explained it already by giving permissions through the business logic (policies and gates in Laravel). Which kind of defeats the point of my permissions_users table. I stand corrected!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi John!
Usually it's easier to attach permissions to roles than to users, because then your
permissions_userstable would explode in size (every new user has to have all its default permissions copied in the system).It also makes it harder to add new permissions, because you have to create a row for each user in the system.
So, let's say that tomorrow I introduce a new resource in the system, with a set of default CRUD permissions, what happens to the users? Can they work on that resource by default or do I have to create 4 permissions multiplied by the number of users in the systems?
What if I want to change the read permission for all the users with a role X? In your schema I have to go to the DB, load all the users with that role, and edit their corresponding read permission.
If instead roles are attached to permissions I can just edit one line :-)
Another approach I like it's Pundit's, in which permissions are inside the business logic, because they might be granted only if the user passes a complex test. Let's say for example that you want to grant access to a resource only if a user was created in a date range and if they have 5 points accrued in your system.
By having permissions written in stone in a table you might have to modify them at runtime by calculating if the user passes the test, then add the specific permission and then let the user pass through. But what happens if the users the day after don't have the 5 points anymore? You are allowing them through even if they shouldn't be allowed. Yes, you could setup a callback for each time they lose a point but... well you know, it's going to explode pretty soon in complexity.
If, instead, permission are part of the business logic, you can easily test them in isolation and have them as complicated as you wish, without relying on a "switch table".
Hope this offers you a possible alternative in case you have a more than trivial setup. Let me know if there's something that's not super clear!
Hi!
I really don't have much to add, your approach is much flexible and clearer. I actually wrote a couple sentences how I used
permission_usersfor "one-off" permissions, but then I deleted it after realizing you've explained it already by giving permissions through the business logic (policies and gates in Laravel). Which kind of defeats the point of mypermissions_userstable. I stand corrected!