Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hey all, So I am working on a practice project with Laravel and I wanted to get some feedback about roles & permissions.
I have users that signed up that would be able to rent a car.
Users that signed and passed an on boarding process (document verification etc) that would be able to list their car as a rental.
Users that are rental companies that will have different commissions applied different regulation and will offer more availability & multiple listings.
And classic administrators which will have access to the back office.
I am wondering if an approach of multiple roles and permissions applied to a role is suitable here. Like user signups gets the default role. If he passes the verification process gets the vendor role. If he is a company gets a "super-vendor" role etc. Does a default role even makes sense ? Does a simpler approach with one distinct role at a time fits better?
I've used https://docs.spatie.be/laravel-permission/v3/introduction/ before and I think it's great but instead of going for this one directly I prefer to hear your take on the matter
Thanks for the feedback
If you read what you've wrote carefully, you will see terms like onboarding process or document verification. So from that it is best to model your system around those terms. I do not see any need for roles. You can have simple fields with one of those terms (or a simplified version of those terms) and use middleware or policies to restrict access in the app.
Thanks @bugsysha so basically you are saying if user has a verified vendor profile (can be as you said a field or a relation holding more data) grant him access to post a listing. If vendor profile is a company profile then access to more parts etc. I like the idea because it's scoped to the business requirements but isn't this pretty much the same like if user finished document verification process grant him the role of vendor which contains the appropriate permissions?
The result can be the same, but then your system is not fully aligned with business logic. You would have to encapsulate that piece of logic to align it with the way you speak.
Or if you do not do that, then you might go down the path where you will have to write a bunch of documentation to explain things (but documentation tend to go stale cause no one is maintaining it) or to have to spend days explaining to new developers what your system does or even to have to throw that implementation away someday.
Bit exaggerating, but have to emphasize how well readable code which is aligned with business requirements is important.
@bugsysha I fully agree, code should be just another medium to express your business domain (big Evans fun here). Maybe it's waterfall thinking here but i can see administrators having exports based on renters/vendors/companies. Statistics scoped to each of them. Navigation conditions etc. A package like https://docs.spatie.be/laravel-permission/v3/introduction/ comes with a lot of helpers for the above. Finally speaking from experience (small one :)) here having worked on similar companies I see that around those concepts like in my example normal users/vendors there are operations roles based on them (managers handling and on boarding vendors etc) if Vendor Managers are good enough of a role to employ them in a company shouldn't this role deserve a place in the software too ?
Not sure I fully understand since your sentence is like a mile long. I would avoid any packages about permissions and roles.
Please or to participate in this conversation.