More advanced and flexible permissions#138

The current permissions system, as simple and reliable as it is, can become quite limiting for more complex projects. This has already been pointed out by various users. For example, user-based permissions, which are necessary e.g. to prevent access to pages based on authorship, are currently impossible.
I’m currently thinking about developing a plugin that will (re)enable the handling of more complex permissions similar to Kirby v2 (see my forum post).
My approach has actually changed since my forum post. At the moment I’m leaning towards a solution where permissions are exclusively handled per user role in the form of php closures outside the user blueprint.
I think it would be possible to create a quite reliable implementation via a plugin. But I read that the permissions system of Kirby v2 was dropped because it was unreliable and hard to maintain. I furthermore read that the callbacks weren’t consistent because of the possibility of changing data and that the current panel could cause problems because it’s not designed to react to changing permissions (see this Issue). I don’t think that handling permissions with hooks or queries is better in this respect. Given my limited knowledge about Kirby, this should be evaluated by a core developer.
I can understand why the Kirby v2 permissions system was replaced in order to make Kirby less complex, but the current solution doesn’t seem ideal either. I like the idea of a plugin that implements more advanced permissions while letting users decide whether they need it or not.

Current permission system problems

• Hard to maintain hierarchy (page permissions can override user permissions and even allow previously restricted access)
• Permissions shouldn’t be part of blueprints whose sole purpose should be to ‘configure the Panel layout’
• Defining permissions in user, page, … blueprints and additionally hooks makes it very difficult to oversee their synergy
• Hooks are sometimes not a solution (e.g. read permission cannot be handled and users can edit pages even if they do not have update permission)

Plugin advantages

• More complex expressions for permissions
• Separation of Concerns
• Single Source of Truth

Plugin Problems

• No site and file models can be defined, which makes it impossible to override their permissions() method (I can’t think of a way to override the ModelPermissions either)
• A rather hacky workaround that makes it difficult to guarantee proper functionality, especially with upcoming kirby releases

Also adding this here for reference: https://github.com/getkirby/ideas/issues/492