Add RBAC support to Backpex

[AshGhannam]

Based on my analysis of Backpex, the library currently offers basic authorization through "simple pattern matching" with optional integration for external authorization libraries . While Backpex excels at rapidly building customizable admin panels with CRUD views, search, filtering, and metrics, it lacks comprehensive Role-Based Access Control (RBAC) functionality that enterprise applications demand.

Adding built-in RBAC to Backpex would provide a standardized framework for defining granular user roles, permissions, and resource-level access controls. This enhancement would eliminate the need for custom authorization logic in each LiveResource, reduce security implementation overhead, and offer enterprise teams the fine-grained access management they require—allowing different user groups (administrators, editors, viewers, department-specific roles) to access only the data and functions relevant to their responsibilities, which is critical for compliance and operational security in large organizations.

High-Level Requirements for RBAC in Backpex :

Core RBAC Framework: The RBAC system should provide a comprehensive role and permission management structure with database schemas for users, roles, permissions, and their associations. It must support hierarchical role inheritance (e.g., Admin inherits Editor permissions), allow many-to-many relationships between users and roles, and provide granular permission definitions at both resource and action levels (create, read, update, delete, custom actions). The system should integrate seamlessly with existing Backpex LiveResources through declarative configuration rather than requiring extensive custom code.

Resource-Level Access Control: Each LiveResource should support fine-grained access controls that can be configured declaratively, including field-level permissions (hide/show specific fields based on roles), row-level security (filter data based on user context), and action-level restrictions (control access to custom actions, exports, imports). The system must provide both static role-based rules and dynamic permission evaluation based on data relationships (e.g., users can only edit records they created or from their department).

Administrative Interface and Developer Experience: Backpex should include built-in administrative views for managing roles, permissions, and user assignments through its own admin interface, making it self-hosted and maintainable. The implementation should offer simple configuration APIs for developers to define role hierarchies and permission mappings, provide clear error messages for unauthorized access attempts, and include optional integration hooks for external identity providers (LDAP, SAML, OAuth) while maintaining backward compatibility with existing authorization patterns.