Custom permission has no target()



I’m implementing a custom permission for a plugin. For some reason I have just an empty target() object inside the permission.

''      => function() {
  error_log(print_r($this, true));
  return true;

Just returns

[Fri Apr 13 10:08:03 2018] Kirby\Event Object
    [type] =>
    [kirby] => 
    [site] => 
    [target] => Obj Object

    [user] => User Object
            ... Full user object here


Any idea why this happens and how I make the target available to the permission?

Thank you,


I think there is no permission called, try instead.


Yes, there is no permission with that name. This should be a custom permission, used by a plugin. I believe I had the same issue with any other custom permission name, like myplugin.permission.


Where is the custom permission defined? I’m not aware that you can define custom panel permissions, but maybe I’ve missed something.


Ah, I just re-read the documentation on this and I missed the part that custom permission are only for “frontend features” … :frowning:
So am I seeing it correctly that I can not define a custom permission to be used in the panel context and I always have to stick to the existing panel permission set?


In principle, I think that is the case.

But if you tell us what you want to achieve, maybe there is an alternative to what you are trying to do.


Sure, I’m using the Sortable-Plugin ( to display pages.
With the extension you can disable sorting (drag and drop) pages using sortable: true in the blueprint. For our use case however this global switch is not enough, we need to have a more fine-granend control based on some conditions in the page wether to switch on and of sorting.

For that I thought handling it with permissions would be the right thing to do. The sortable plugin also hooks into or permissions to control the available actions. However there is no standard permission available, so I was thinking about creating a custom one.

Does this make sense?


I see, but theoretically, the should be covered by the, although I haven’t really tested this.

Edit: That seems to work, if I set

'' => false

in my editor role file, this user role can’t sort pages.

After all, this is what the plugin uses to check if a given page may be sorted:

However, interestingly, the plugin makes use of

$layouts->attr('data-sortable', site()->user()->can('') ? 'true' : 'false');

Hm… :thinking: Or is that a result of your PR? Looks like it…


I just merged it this morning.
I will try to have a closer look at this at the weekend. Perhaps I can make this work somehow.

The general problem with the existing permission in the context of modules is that the sorting and switching the visibility are not coupled together. At least not in the frontend.

It probably is an edge case but I can see the benefits of being able to have a seperate permission for both actions.


I agree absolutely. One is changing the position of a page within the visible pages. Another is changing the visibility state of a page. I don’t even think this is an edge case. Even though you can probably manage this in a user role somehow.

But the naming of this stuff is confusing, to say the least.


Thank you @lukaskleinschmidt for looking into it.
I thought I had tested the permission within my scenario but I must have missed something. Maybe I just tested returning true or false from the permission function and didn’t check the access to the target().
So sorry, for having this now in your code. I hope we can find a proper way to solve this. Just reach out, if I can help anything.


Well I got triggered and needed to fix it now :wink:
It should work now with v2.4.0.


Thank you!
Works perfect.

Have a nice weekend,