Feature Request
Description:
Implement a role-based access control (RBAC) system for the Admin UI, allowing different levels of access (e.g., viewer, editor, admin) for managing materialized views.
Use Case:
In larger teams, it's important to control who can create, edit, or refresh materialized views. For example, a business analyst might have view-only access, while a data engineer has full control.
Proposed Solution:
- Define a set of roles (e.g.,
:viewer, :editor, :admin).
- Provide a way to map these roles to the host application's
current_user (e.g., via a lambda in the initializer).
- Enforce permissions in the UI and API endpoints based on the user's role.
RSpec Tests:
- Configure the authorization callback for different roles.
- (UI) As a 'viewer', visit the dashboard and verify that 'edit' and 'new' buttons are not visible.
- (UI) As an 'editor', verify that CRUD buttons are visible and functional.
- (API) Send a
DELETE request as a 'viewer' and verify it is rejected with a 403 Forbidden status.
Checklist:
Feature Request
Description:
Implement a role-based access control (RBAC) system for the Admin UI, allowing different levels of access (e.g., viewer, editor, admin) for managing materialized views.
Use Case:
In larger teams, it's important to control who can create, edit, or refresh materialized views. For example, a business analyst might have view-only access, while a data engineer has full control.
Proposed Solution:
:viewer,:editor,:admin).current_user(e.g., via a lambda in the initializer).RSpec Tests:
DELETErequest as a 'viewer' and verify it is rejected with a 403 Forbidden status.Checklist: