Wildcard permissions are very confusing.

[martinsnajdr]

I find working with Wildcard permissions quite confusing to be honest.

Let's say I have an example app that has a navigation that display different types of "resources" as links. What I need is to display the links based on user permissions – if the user has any permission to somehow interact with the resource, I need to display the link.

So naturally I would use the Wildcard permission like this (for simple Create / Read / Update / Delete):

Permission::create(['name' => 'resource.view']);
Permission::create(['name' => 'resource.create']);
Permission::create(['name' => 'resource.edit']);
Permission::create(['name' => 'resource.delete']);

$role->givePermissionTo([
    'resource.view',
    'resource.create',
    'resource.edit',
    'resource.delete'
]);

And then I would use can directive to display the menu item in blade (I know it's not working like that right now, but I think it should be considered):

@can('resource.*')
    My menu item
@endcan

This would the translate to – if the user has any permissions starting with 'resource', the user has the permission. I understand that the current functionality of Wildcard permissions is not random and that there are surely some reasons why it works like it works, but I found the documentation of Wildcard permissions very misleading.

Instead I have to do this (because the view permission is a "dependency" to other permissions, I can check just the view to display the menu item):

@can('resource.view')
    My menu item
@endcan

Let's say I have more complex example – where some roles can manage only their own resources. So I have few extra permissions:

Permission::create(['name' => 'resource.own.view']);
Permission::create(['name' => 'resource.own.create']);
Permission::create(['name' => 'resource.own.edit']);
Permission::create(['name' => 'resource.own.delete']);

Then I have to check it like this

@canany(['resource.view', 'resource.own.view'])
    My menu item
@endcanany

Which works, but it doesn't use the simplicity of the Wildcards. Also what I find quite confusing is using permissions like this (example from docs):

'posts,users.create,update,view'

What I have read in different github issue, I have to specifically create permission that has the same "name". I would expect it would work like this:

Permission::create(['name' => 'resource.view']);
Permission::create(['name' => 'resource.create']);
Permission::create(['name' => 'resource.edit']);
Permission::create(['name' => 'resource.delete']);

$role->givePermissionTo('resource.view,create,edit,delete');

Like some kind of shorter version to give permissions to a role. Because then I could add different permission stack to different role using the same permissions.

$different_role->givePermissionTo('resource.view,edit');

And then use can directive like this

@can('resource.*')
    Any user with any resource permission can see this
@endcan

@can('resource.create,delete')
    Any user with permission to create and delete can see this
@endcan

@can('resource.own.*')
    Any user with permission that starts with "resource.own.*" can see this
@endcan

I don't say I'm right, but from my point of view, this is what I would expect the wildcards to work – to be really useful. Right now I can't really see how to write the whole @canany(['resource.view', 'resource.own.view']) more effectively using wildcards. Any tips?

[polycode-nz]

Old post but I agree. ANY seems like a much more useful and common use case than ALL.

Checking permissions for a multi level nav for example. At the moment this is arduous.

Also seems odd to me that there is @hasanyrole blade directives but not for permissions when best practices states:

"It is generally best to code your app around testing against permissions only"

[angeljqv]

Feel free to make a PR for improving that

[polycode-nz]

I've been using Laravel for about 6 weeks. I doubt I could be useful, yet.

This is a discussion and "do it yourself" isn't much of one.

Is there any plans/roadmap to include an any functionality in the package? Or perhaps theres a reason why it hasn't been? I see there is hasAnyPermission and hasAnyDirectPermission methods in the HasPermissions trait.

How I got around it so far is I made a permission to match to each one of my nav links. For example Nav.Accidents.

When any Accidents.Create(Read/Update/Delete) permission is assigned to a Role I also assign Nav.Accidents.

For multi level I have Config.Related Data.Accidents.Age Ranges. Each part maps to a nav permission so I just explode on the . loop over it and do the same assigning of Nav.Config, Nav.Related Data etc.

In the view of the nav I just need to check Nav.Config instead of looking at any of the 100's of permissions that might be under it.

I added a couple columns to the permissions table to keep track of what type of permission it is (system/navigation or not) to keep the UI clean, for example:

[parallels999]

Read wildcard tests for examples, also you could overwrite and customize wildcard logic for doing it "less confusing"

[polycode-nz]

"less confusing" isn't a great title. Hows "Unexpected".

You see no merit in this approach?