What is the current Kirby best practice to restrict the panel content visible/editable for multi-users installs? I had to handle a Kirby backend last year with a “student” role and 100 students each editing their own page and not able to see/edit anything else and had to resort to write lot of custom filter logic on hooks.
I was wondering if recent updates have made this easier? I have a client who wants to have a database of “events” that multiple users can add/edit to but not see/edit each-others. Is it still only down to write custom functions on page hooks? Is the solution to have different site blueprints for different user roles loaded via plugin still the only solution?
Would be great to be able to easily restrict content access for each users, for example being able to only see some page blueprints if they match the user ID would be a huge improvement. Having to do it all manually opens lot of doors for security issues… Or did I miss some recent changes in 3.5?
Hey, great thanks!
So still seems like the official go-to solution is to load different site/page blueprints per user role manually. I think something like Bouncer goes toward a good core solution, being able to declare in user blueprints what they can see/access. Alternatively being able to simply declare site/page blueprints by having the user role slug in the name, similarly to languages, could be a very nice option, something like:
site.yml for default
site.client.yml for client user role
@Kirby Team: is there any improvement to user access permissions to be expected in the near future?
Enhanced permissions are definitely planned for the future, but as far as I know not necessarily for the near future (lets say next few months).
Alright, good to know. Then I won’t count on it for the next few projects but hopefully something more refined lands into core by the end of the year 
I just wanted to check in on the dev roadmap of Kirby regarding that issue, is this still to be expected in the “kind of distant future”?
I actively need this on multiple site installs and it just doesn’t feel good to patch things up to hide content by overwriting with custom queries and css in the Panel…
1 Like
Should I assume there is no ETA for this feature and keep using the current workarounds?
I think the new dynamic blueprints feature goes in the right direction, at least it would allow you to create different blueprint settings based on user roles programmatically, as long as you don’t need access to dynamic page content:
But yes, no ETA for more fine-grained user permissions.
Thanks, this is pretty much what I use now, to have different site.yml for each user roles, and having author IDs attached to pages to filter and prevent viewing/editing.
My main concern is that since this is not a native feature it’s hard to reason about second-order effects when adding features or fields later-on that might expose cross-user’s private content inadvertently. For small non-critical sites it’s not really a problem, but when a client requests users to have strictly access to their own content it’s hard to guarantee that there is no low-level separation of content.
Thanks for replying, I’ll follow the dev roadmap patiently.
1 Like