Kirby 2.4.0 beta 2 - Wording of permissions

Kirby 2 Suggestions đź’ˇ
1

@bastianallgeier:

Thank you and your team for this great improvement “Permissions”. I played around with beta 1 / 2 during the past time and it runs very good.

So the following is not aimed to change the real code but the interface to the permissions.

If I look at Kirby docs: Available permissions, I see some inconstancies in the names of the permissions.

All permissions (without “panel.access”, where this exception is ok) consist of three words each connected by a dot:

  • the first word is allways “panel”,
  • the second word describes the aim of the special persimission
  • the third word describes the kind of the special persimission

But there are three permissions, that follow not the same word building rules of the others:

  1. panel.access.options
  2. panel.access.users
  3. panel.site.update

In detail:
the first and the third of these three permissions belong to the “Site options”,
the second belongs to the “Users menu”.

So my idea is to change the names of these three permissions, e.g. like:

  1. panel.access.options - > panel.options.access *)
  2. panel.access.users - > panel.user.access *)
  3. panel.site.update - > panel.options.update

[Edit: *) = changed because of the following hint from @jbeyerstedt]

May be, if you change the the third word “read” to “access”, everywhere where it occurs, this would say more, what the particular permission does.

Thanks for your time.

Supplement:

I know, that this will break the configuration of testers like me. But in a beta version in front of the first running version with permissions this is better than you will do that some versions later.

HeinerEF

1 Like
2

I can understand your idea, but this:

could not be done, because there is already a permissions option named panel.user.read and these are not the same.

I agree, that it’s a bit confusing, that panel.access.options and panel.site.update are in separate groups. So I think, these should be in the same site group, because they change permissions to the site object.
panel.access.options → panel.site.read
panel.site.update : keeps the same

So there would be panel.access and panel.access.users left in the panel.access namespace/ group, which would be fine.

So in my opinion, panel.access.options is the only permission, which does not follow the “rules” of the others.
But I don’t know, how these changes would affect the wildcards and how the permissions are tied to hooks and other “events” in the panel. Because most of the permissions are pretty much the same, as the hooks.

1 Like