Widgets are auto-hidden when *-permission is false

I noticed that custom widgets are auto-hidden in the dashboard if the the role of the user has '*' => false.
This also applies to built-in widgets which is no problem because built-in widgets have distinct permissions which can be set to true.
So if your custom widgets do not come with a distinct permission (I dont know if they even can) those will not be shown in the dashboard.
Right now I see no way to make them appear for users which have '*' => false. Do you know of any?

I want to keep the '*' => false because that way new permissions are not automatically turned on for very restricted users.

I tested this a bit, and in general and in theory, you can set panel.widget.custom_widget to true or false just like for any default widget. Having said that, it depends on a plugin’s individual settings whether or not this has any effect.

To give you an example: My Logger plugin uses a widget to access a custom Panel View. However, the widget is only registered if the current user’s role is defined in the plugin settings. Here is the relevant code:

if(site()->user() && in_array(site()->user()->role(), c::get('logger.roles', ['admin']))) {
  kirby()->set('widget', 'logger', __DIR__. DS . 'widgets' . DS . 'logger');
}

If you don’t set anything in your config, only an admin user will ever get to see this widget, no matter what you define in your permissions (maybe I should change this and respect role settings, actually, the role definition would then overwrite the config settings).

What custom widgets did you test with?

I tested it with content-viewer and broken-links-widget.

It looks to me like content-viewer is using roles/permissions only for showing a edit-button. (if user is admin)
I don’t see any code that actually changes the visibility of the widget based on roles/permissions.
Which means that Kirby has somewhere implicit logic to hide widgets if '*' => false was set, right?

Regarding how you handle that in the Logger Plugin:
It’s good that there is a option that makes the whole issue visible to the user. But IMHO it would be better to have stuff like that controlled from the roles/permission side instead of the plugin config. If you use a special permission for the widget, users are flexible to the max in whom they want the widget to be shown to. (not just roles)

Yes, and that is correct, in my opinion, in the same way as it hides the built-in widgets. As I said, the Panel also has a built-in method to make these widgets visible based on their name.

In the case of the content viewer, unfortunately the widget is not called content-viewer but simply widget, so if you set

    'panel.widget.widget' => true

And for the broken links widget:

    'panel.widget.broken-links' => true

in your role file, the widgets will be visible for your user.

If you don’t use roles because you don’t need them, it makes sense to use plugin settings to determine if the plugin should be visible or not. In fact, since this defaults to the admin user anyway, in the best of cases the user doesn’t have to set anything permissions. As I said, I will change that so that role permissions are also checked but keep the general config setting.

Okay sorry, I obviously got the part about the built-in widget permissions wrong. Thanks for the stellar support! :slight_smile:

I think that’s a pretty decent way of tackling the issue. Is that stated anywhere in the Docs?
Maybe this information has to go to the widget doc page. Thats where I was looking for it because it’s in some sense part of the widget API. It would also remind widget Authors to consider to think of a good permission name for the widget. So we dont end up again with widgets where you have to 'panel.widget.widget' => true, which becomes a pretty bad situation if you have two widgets doing that.

I don’t think it is documented. I just thought it might be like this and played around to find out. So, absolutely agreed, this should be in the docs.

Yeah, that’s definitely not how it should be. However, I would put this information in the docs about registering components.

For anyone that stumbles across the same issue with the content-viewer:
I made a PR for that: https://github.com/calebgrove/content-viewer/pull/6

Just wanted to add an issue there when I saw you already had ;).

Fortunately it looks like there are not many people doing that: GitHub Search

1 Like