Can we have negative roles/ permissions? or Model to Model roles?

[jcc5018]

I did see a similar request to this from a few years ago but I have not seen any change in the code base to consider it.

First request is to have negative permissions.

Example if you wish to limit a users ability to do something like make suggestions or whatnot. it'd be easier to have a "can_not_do" permission than to set a "can_do" permission that is default.

I feel this can be easily updated with a "is_negative" attribute in the permissions and or role table so that positive and negative roles can be distinguished

and then create a few methods to block instead of enable access if the permission is present.

2. Second request would be to have model to model roles. Ideal for social applications or similar where a permission may be specific between two distinct models such as User to user relations, or User to group

I think this would just require a trait that adds a role or permission column to a M:M pivot table of the given models. Ie a friend table maybe have user_id 1 user_id 2, where a permissions column may indicate "restrict_messaging" or "allow_sharing"

or a group_user pivot could have the admin role, or "allow_posts" permissions.

Any traits could just provide the functionality to set these model to model permissions/ roles in a json column or similar.

otherwise an additional column would need to be added to the model_has_roles/ permissions tables to account for the second model.

[erikn69]

#1934
#1895 (comment)
#1936

There have already been several discussions about this, an answer has already been given, in short, it is not going to happen.

[jcc5018]

so because there are a couple of 3 year old posts, its never going to happen? If enough people desire something, it could happen. Or if i can figure out how to make a request and other requirements, I might be able to make it happen. Though, i'd prefer to leave it up to people who know what they are doing as i am not the most experienced programmer. I don't think it would need much more than the suggested DB additions and a few new methods to implement.

[erikn69]

so because there are a couple of 3 year old posts

Yes, but better read the maintainer's response #1593 (comment), #1513 (comment), #1294 (comment)

This is by design.

This package only stores and authorizes permissions/roles in an additive manner. It does not offer "give everything and then start subtracting things".

There are many other ways to handle that sort of thing at the application level. Usually it's best to first reconsider your approach to be "only give what they're actually allowed to do".

But if you really need to "give all first and then start subtracting", you could use Model Policies or custom Gate rules in an AuthServiceProvider. For example, if your products model has some property that already can be used to determine that user should not have access then you could use that property to deny the user via a model policy or custom Gate rule that checks both the wildcard "all" that you first set up, and then checks the additional property to handle the denial portion of your logic.

That said, if the combination of adding-all-and-then-denying-partial permissions is crucial to your app then perhaps the Bouncer package may be a better fit for your needs.

But in my experience the practice of denying-after-over-allowing often means something should be re-evaluated in the app logic to improve its simplicity.

that is the response of "people who know what they are doing"

but, feel free to open a pull request, maybe you will make it possible

[jcc5018]

while i understand there may be other ways to handle this, and i will look into policies and such when i get to that part of my app
This is also a discussion for ideas. And i do not believe my suggestions would be too difficult to implement from someone who is more familiar with their code base. Im likely to screw things up. But if you disagree, that is fine. As far as i know you are not the package developer.

This is simply something to think about for extra features to an already good package.

[drbyte]

1. Negative permissions:
   I see your point, and I get where you're coming from.
   And still I pretty much stand by what I've posted before, as quoted above.
   I think you could do what you're after by extending the traits in this package into your own app and adjusting the logic accordingly (with the requisite db fields too).
   But, as I wrote before, it's probably worth just creating permissions "named" as "forbidden to xyz" (some negative thing) and then in your app check "backwards" against it. eg: if (hasRole('foo') && !hasPermissionTo('forbidden to comment')). You could even create a helper function like isNotAssigned('forbidden to comment') where isNotAssigned() returns !hasPermissionTo($foo).
   That's probably the simplest way to accommodate it with this package.

[jcc5018]

i thought about the permission approach, which is kind of the basis to my suggestion. The main thing that would help in this approach is a simple boolean in the permission or role database to indicate if it is a positive or negative trait. This would help the end user to separate the two. Then a basic check in a function to see if positive or negative would either allow or restrict the request

[drbyte]

2. By model-to-model-roles, do you mean "inherit from other models' roles"?

[jcc5018]

no, it would be useful between two users or a user and a group or any other relation.

as i said in my original set up this would probably be best in the pivot tables, so im not sure if that is something that can be handled by a trait or if it would require some manual set up. but a group user relation may need an "group admin" role, but a user wouldnt be an admin for every group, so the specified group would need to be determined.

so I am wondering, if we use the existing functionality of the package if having an optional parameter that defines the second model, perhaps the code could then handle inserting into the defined pivot tables based on that parameter. I would imagine the set up for the developer would be adding the appropriate column in their database tables, and perhaps a trait to models that have specific permissions.

I havent explored trying to implement it on my own, but I think there are a lot of cases where this would be helpful

and again, another example would be user to user interactions, where a role might be "follower, friend, family, etc" with set permissions. But defining a friend to a single user wouldnt distinguish between specific relationships. I could probably come up with something, but its not going to be as good as what this team provides