Spatie permission not only for 'features' but also other dimensions like orders from manufacturer X

[nicktc]

Hey,

We like to improve our ACL role based system. Currently we are allowing our users to have 'direct permissions', permissions directly assigned to the user. We don't want to do this anymore, and only allow role based permissions. The laravel-permission package is beautiful to accomplish this. It's perfect to get permissions right for features, like 'edit document', 'create task', etc.

But for some of our models (like sales) we like the ability to have a role that will be able to access a part of the sales, namely the sales for the supplier of the sale. So that the supplier is able to login (with a 'supplier role'). That supplier won't be able to 'delete sales', etc. But the main difference with other roles is that this role will only be able to view sales that are associated (1 sale can only have 1 supplier) with the configured supplier(s) for that role. So next to a feature dimension, we'd also like to add a 'data' dimension for the permissions.

I have checked the documentation, the only thing that I could find that's a bit the same is the team_id. Is that the right way to do this for the supplier dimension as well? And in the future I could imagine that we might have more of these dimensions, like manufacturer, etc.

Could we also use this system to check if a user should have access to a particular sale? A user can only access a sale of which he is the owner or assignee.

Thanks,

Nick

[parallels999]

#2426 (comment)

[nicktc]

Thanks, this works for stuff like do you have access to 'view sale' for 'supplier X', but can you also use this to have some index controller return a list of sales, where those sales are only for supplier X?

[drbyte]

Perhaps your Sale model could have an attribute or scope to filter those. And then you could use that scope along with a Model Policy to filter by permission or role if needed.

[nicktc]

We have scope function's on the model, but was wondering if you can store that within the policy, and that Laravel will automatically apply it. It would be strange to have 2 definitions on authorization for a particular model; scopes for listing of records, and policies for accessing a particular record.

[drbyte]

Maybe I'm not fully understanding your scenario.

I'm inclined to define authorization in a policy (or just a simple authorization rule in an AuthServiceProvider), and then in my Model scope make reference to that rule, in order to not re-define it in multiple places.

If I'm not making sense in terms of your scenario, do you mind posting some code, or pseudo-code to paint the broader picture?