rabarber 5.0.0 → 5.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1de40ccff8f5d39718c2c908913c5a67149eeada18598a37b51ec53e900200cc
-  data.tar.gz: d9a02594d2c2215499cd2609d57f3fa14e796d9b3df6d0176b5fa1b510cf2d72
+  metadata.gz: 874cd3840269f288baec19fd5e240afdd6b06e3e5b81d703eb30e8e62283fb32
+  data.tar.gz: 117d060ffe53ae884b657c1d79a94d9762de1de8b6726659128d7be805c77e24
 SHA512:
-  metadata.gz: e7862b8b5793a4c3076b2e9c34eec91df58b79b629273b7e2fc9a6c97b74d3a42b7ac53bd85bad8ee270549c13a6d8e5d747ea6fe3472b2d72f067aafc247028
-  data.tar.gz: a9f1cbf65045fde78aeac07e6217caca037dc1f85e97065e26a07f1c52bfce46deb4e60513617df6572a0883e792dacbf70a18c0f19d14f31e97171420903cc9
+  metadata.gz: c2207e66e0743b7e5a81acfcc2707d00313fa2a8e9d8e652c7f0dc41b331d8cfa0c4d3504ff5e857606666f0145023a68e8c6d961d6285d48e36c435d4597a38
+  data.tar.gz: ea1ab97b91cb45611f4ca24a6418484a0b7634d00b0f96cec8485ba543500fc763a33f1e0cbaf7027a8a375623e91481ca1de74d47f50cf86fe5b91bfe456d0b

data/CHANGELOG.md

@@ -1,3 +1,14 @@
+## v5.1.0
+
+### Features:
+
+- Added `revoke_all_roles` method to revoke all user roles at once
+
+### Bugs:
+
+- Fixed HTTP status code for unauthorized non-HTML requests from 401 to 403
+- Fixed some error types for consistency
+
 ## v5.0.0
 
 ### Breaking:

data/README.md

@@ -1,60 +1,37 @@
-# Rabarber: Simplified Authorization for Rails
+# Rabarber: Role-Based Authorization for Rails
 
 [![Gem Version](https://badge.fury.io/rb/rabarber.svg)](http://badge.fury.io/rb/rabarber)
 [![Github Actions badge](https://github.com/brownboxdev/rabarber/actions/workflows/ci.yml/badge.svg)](https://github.com/brownboxdev/rabarber/actions/workflows/ci.yml)
 
-Rabarber is a role-based authorization library for Ruby on Rails. It provides a set of tools for managing user roles and defining authorization rules, with support for multi-tenancy and fine-grained access control.
+Rabarber is a role-based authorization library for Ruby on Rails that focuses on controller-level access control. Rather than answering domain questions like "can this user create a post?", Rabarber answers "can this user access the create post endpoint?", providing a clean separation between authorization and business logic.
 
----
+**Key Features:**
 
-**Example of Usage**:
-
-Consider a CRM system where users with different roles have distinct access levels. For instance, the role `accountant` can interact with invoices but cannot access marketing information, while the role `marketer` has access to marketing-related data. You can define such authorization rules easily with Rabarber.
-
----
-
-And this is how your controller might look with Rabarber:
-
-```rb
-class TicketsController < ApplicationController
-  grant_access roles: :admin
-
-  grant_access action: :index, roles: :manager
-  def index
-    # ...
-  end
-
-  def delete
-    # ...
-  end
-end
-```
-
-This means that `admin` users can access everything in `TicketsController`, while `manager` role can access only `index` action.
+- Role-based authorization
+- Controller-level access control
+- Multi-tenancy support through contextual roles
+- Dynamic authorization with conditional logic
+- View helpers for role-based content rendering
 
 ## Table of Contents
 
-**Gem usage:**
+**Gem Usage:**
   - [Installation](#installation)
   - [Configuration](#configuration)
-  - [Role Assignments](#role-assignments)
   - [Role Management](#role-management)
-  - [Authorization Rules](#authorization-rules)
-  - [Dynamic Authorization Rules](#dynamic-authorization-rules)
-  - [Context / Multi-tenancy](#context--multi-tenancy)
-  - [When Unauthorized](#when-unauthorized)
-  - [Skip Authorization](#skip-authorization)
+  - [User Role Methods](#user-role-methods)
+  - [Controller Authorization](#controller-authorization)
+  - [Dynamic Rules](#dynamic-rules)
+  - [Multi-tenancy / Context](#multi-tenancy--context)
   - [View Helpers](#view-helpers)
 
+
 **Community Resources:**
-  - [Problems?](#problems)
   - [Contributing](#contributing)
+  - [License](#license)
   - [Code of Conduct](#code-of-conduct)
   - [Old Versions](#old-versions)
 
-**Legal:**
-  - [License](#license)
-
 ## Installation
 
 Add Rabarber to your Gemfile:
@@ -69,19 +46,17 @@ Install the gem:
 bundle install
 ```
 
-Generate a migration to create tables for storing roles. Run the generator with the table name used by the model that represents users in your application. For example, if the table is `users`, run:
+Generate the migration for role storage (replace `users` with your user table name if different):
 
 ```shell
-rails g rabarber:roles users
-```
-
-Rabarber supports UUIDs as primary keys. If your application uses UUIDs, add `--uuid` option:
+# For standard integer IDs
+rails generate rabarber:roles users
 
-```shell
-rails g rabarber:roles users --uuid
+# For UUID primary keys
+rails generate rabarber:roles users --uuid
 ```
 
-Finally, run the migration:
+Run the migration:
 
 ```shell
 rails db:migrate
@@ -89,507 +64,323 @@ rails db:migrate
 
 ## Configuration
 
-If customization is required, Rabarber can be configured using `.configure` method in an initializer:
+Configure Rabarber in an initializer if customization is needed:
 
 ```rb
 Rabarber.configure do |config|
-  config.cache_enabled = true
-  config.current_user_method = :current_user
-  config.user_model_name = "User"
+  config.cache_enabled = true                 # Enable role caching (default: true)
+  config.current_user_method = :current_user  # Method to access current user (default: :current_user)
+  config.user_model_name = "User"             # User model name (default: "User")
 end
 ```
 
-- `cache_enabled` determines whether roles are cached to avoid unnecessary database queries. Roles are cached by default. If you need to clear the cache, use `Rabarber::Cache.clear` method.
-- `current_user_method` defines the method used to access the currently authenticated user. Default is `:current_user`.
-- `user_model_name` sets the name of the model representing the user in your application. Default is `"User"`.
-
-## Role Assignments
-
-Rabarber automatically augments your user model (defined via `user_model_name` configuration) with role-related methods.
-
-**`#assign_roles(*roles, context: nil, create_new: true)`**
-
-To assign roles, use:
+To clear the role cache manually:
 
 ```rb
-user.assign_roles(:accountant, :marketer)
-```
-
-By default, it will automatically create any roles that don't exist. To assign only existing roles and prevent automatic creation, pass `create_new: false`:
-
-```rb
-user.assign_roles(:accountant, :marketer, create_new: false)
-```
-
-The method returns an array of roles assigned to the user.
-
-**`#revoke_roles(*roles, context: nil)`**
-
-To revoke roles, use:
-
-```rb
-user.revoke_roles(:accountant, :marketer)
-```
-
-Roles the user doesn’t have are ignored.
-
-The method returns an array of roles assigned to the user.
-
-**`#has_role?(*roles, context: nil)`**
-
-To check whether the user has a role, use:
-
-```rb
-user.has_role?(:accountant, :marketer)
-```
-
-It returns `true` if the user has at least one of the given roles.
-
-**`#roles(context: nil)`**
-
-To get the list of roles assigned to the user, use:
-
-```rb
-user.roles
-```
-
-**`#all_roles`**
-
-To get all roles assigned to the user, grouped by context, use:
-
-```rb
-user.all_roles
-```
-
-**`.assignees(role_name, context: nil)`**
-
-To get all the users to whom the role is assigned, use:
-
-```rb
-Rabarber::Role.assignees(:admin)
+Rabarber::Cache.clear
 ```
 
 ## Role Management
 
-To manipulate roles directly, you can use the following methods:
-
-**`.add(role_name, context: nil)`**
-
-To add a new role, use:
+### Direct Role Operations
 
 ```rb
+# Create a new role
 Rabarber::Role.add(:admin)
-```
-
-This will create a new role with the specified name and return `true`. If the role already exists, it will return `false`.
 
-**`.rename(old_role_name, new_role_name, context: nil, force: false)`**
-
-To rename a role, use:
-
-```rb
+# Rename a role
 Rabarber::Role.rename(:admin, :administrator)
-```
+Rabarber::Role.rename(:admin, :administrator, force: true) # Force if role is assigned to users
 
-The old role must exist. If it doesn’t, an error is raised. If a role with the new name already exists, the method returns `false` and the rename fails.
+# Remove a role
+Rabarber::Role.remove(:admin)
+Rabarber::Role.remove(:admin, force: true) # Force if role is assigned to users
 
-The rename also fails if the role is assigned to any user. To force it, use:
+# List available roles
+Rabarber::Role.names
+Rabarber::Role.all_names # All roles grouped by context
 
-```rb
-Rabarber::Role.rename(:admin, :administrator, force: true)
+# Get users assigned to a role
+Rabarber::Role.assignees(:admin)
 ```
 
-**`.remove(role_name, context: nil, force: false)`**
+## User Role Methods
+
+Your user model is automatically augmented with role management methods:
 
-To remove a role, use:
+### Role Assignment
 
 ```rb
-Rabarber::Role.remove(:admin)
-```
+# Assign roles (creates roles if they don't exist)
+user.assign_roles(:accountant, :manager)
 
-The old role must exist. If it doesn’t, an error is raised. The method returns `true` if successful.
+# Assign only existing roles
+user.assign_roles(:accountant, :manager, create_new: false)
 
-If the role is assigned to any user, removal will fail. To force it, use:
+# Revoke specific roles
+user.revoke_roles(:accountant, :manager)
 
-```rb
-Rabarber::Role.remove(:admin, force: true)
+# Revoke all roles
+user.revoke_all_roles
 ```
 
-**`.names(context: nil)`**
-
-If you need to list the roles available in your application, use:
+### Role Queries
 
 ```rb
-Rabarber::Role.names
-```
-
-**`.all_names`**
+# Check if user has any of the specified roles
+user.has_role?(:accountant, :manager)
 
-If you need to list all roles available in your application, grouped by context, use:
+# Get user's roles
+user.roles
 
-```rb
-Rabarber::Role.all_names
+# Get all roles grouped by context
+user.all_roles
 ```
 
-## Authorization Rules
+## Controller Authorization
 
-Include `Rabarber::Authorization` module in the controller where you want to define authorization rules. Typically, it is `ApplicationController`, but it can be any controller of your choice. Then use `.with_authorization(options = {})` method, which accepts the same options as Rails’ `before_action`, allowing you to perform authorization checks selectively.
+### Basic Setup
+
+Include the authorization module and configure protection:
 
 ```rb
 class ApplicationController < ActionController::Base
   include Rabarber::Authorization
 
-  with_authorization
-
-  # ...
+  with_authorization # Enable authorization for all actions
 end
 
 class InvoicesController < ApplicationController
-  with_authorization only: [:update, :destroy]
-
-  # ...
+  with_authorization only: [:update, :destroy] # Selective authorization
 end
 ```
 
-You must ensure the user is authenticated before authorization checks are performed.
+Authorization requires an authenticated user.
 
-To define authorization rules, use `.grant_access(action: nil, roles: nil, context: nil, if: nil, unless: nil)` method.
+### Skip Authorization
 
-The most basic usage of the method is as follows:
+You can also selectively skip authorization:
 
 ```rb
-module Crm
-  class InvoicesController < ApplicationController
-    grant_access action: :index, roles: [:accountant, :admin]
-    def index
-      @invoices = Invoice.all
-      @invoices = @invoices.paid if current_user.has_role?(:accountant)
-      # ...
-    end
-
-    grant_access action: :destroy, roles: :admin
-    def destroy
-      # ...
-    end
-  end
+class TicketsController < ApplicationController
+  skip_authorization except: [:create, :update, :destroy]
 end
 ```
 
-This grants access to `index` action for users with `accountant` or `admin` role, and access to `destroy` action for `admin` users only.
+### Authorization Rules
 
-You can also define controller-wide rules (without `action` argument):
+Define access rules using `grant_access`:
 
 ```rb
-module Crm
-  class BaseController < ApplicationController
-    grant_access roles: [:admin, :manager]
-
-    grant_access action: :dashboard, roles: :marketer
-    def dashboard
-      # ...
-    end
-  end
-end
+class TicketsController < ApplicationController
+  # Controller-wide access
+  grant_access roles: :admin
 
-module Crm
-  class InvoicesController < Crm::BaseController
-    grant_access roles: :accountant
-    def index
-      # ...
-    end
+  # Action-specific access
+  grant_access action: :index, roles: [:manager, :support]
+  def index
+    # Accessible to admin, manager, and support roles
+  end
 
-    def delete
-      # ...
-    end
+  grant_access action: :destroy, roles: :admin
+  def destroy
+    # Accessible to admin role only
   end
 end
 ```
 
-In this example, `admin` and `manager` have access to all actions in `Crm::BaseController` and its descendants, while `accountant` role has access only to the actions in `Crm::InvoicesController`. Users with `marketer` role can only see the dashboard.
+### Additive Rules
 
-You can also omit roles to allow unrestricted access:
+Rules are additive across inheritance chains and for the same actions:
 
 ```rb
-class OrdersController < ApplicationController
-  grant_access
-  # ...
+class BaseController < ApplicationController
+  grant_access roles: :admin # Admin can access everything
 end
 
-class InvoicesController < ApplicationController
-  grant_access action: :index
-  def index
-    # ...
-  end
+class InvoicesController < BaseController
+  grant_access roles: :accountant # Accountant can also access InvoicesController (along with admin)
+
+  grant_access action: :index, roles: :manager
+  grant_access action: :index, roles: :supervisor
+  # Index is accessible to admin, accountant, manager, and supervisor
 end
 ```
 
-This allows everyone to access `OrdersController` and its descendants as well as `index` action in `InvoicesController`.
+### Unrestricted Access
 
-Rules defined in descendant classes don't override ancestor rules but rather add to them:
+Omit roles to allow unrestricted access:
 
 ```rb
-module Crm
-  class BaseController < ApplicationController
-    grant_access roles: :admin
-  # ...
-  end
+class UnrestrictedController < ApplicationController
+  grant_access # Allow all users
 end
 
-module Crm
-  class InvoicesController < Crm::BaseController
-    grant_access roles: :accountant
-  # ...
-  end
+class MixedController < ApplicationController
+  grant_access action: :index # Unrestricted index action
+  grant_access action: :show, roles: :member # Restricted show action
 end
 ```
 
-This means that `Crm::InvoicesController` is still accessible to `admin` but is also accessible to `accountant`.
+### Custom Unauthorized Handling
 
-This also applies when defining multiple rules for the same controller or action:
+Override `when_unauthorized` method to customize unauthorized access behavior:
 
 ```rb
-module Crm
-  class OrdersController < ApplicationController
-    grant_access roles: :manager, context: Order
-    grant_access roles: :admin
-
-    grant_access action: :show, roles: :client, context: -> { Order.find(params[:id]) }
-    grant_access action: :show, roles: :accountant
-    def show
-      # ...
-    end
+class ApplicationController < ActionController::Base
+  include Rabarber::Authorization
+
+  with_authorization
+
+  private
+
+  def when_unauthorized
+    # Default behavior: redirect back (HTML) or return 403 (other formats)
+    # Custom behavior example:
+    head :not_found # Hide existence of protected resources
   end
 end
 ```
 
-This will add rules for `manager` and `admin` roles for all actions in `Crm::OrdersController`, and for `client` and `accountant` roles for the `show` action.
+## Dynamic Rules
 
-## Dynamic Authorization Rules
-
-For more complex scenarios, Rabarber supports dynamic authorization rules:
+Add conditional logic to authorization rules:
 
 ```rb
-module Crm
-  class OrdersController < ApplicationController
-    grant_access roles: :manager, if: :company_manager?, unless: :fired?
-
-    def index
-      # ...
-    end
-
-    private
-
-    def company_manager?
-      Company.find(params[:company_id]).manager == current_user
-    end
-
-    def fired?
-      current_user.fired?
-    end
-  end
-end
+class OrdersController < ApplicationController
+  # Method-based conditions
+  grant_access roles: :manager, if: :company_manager?, unless: :suspended?
 
-module Crm
-  class InvoicesController < ApplicationController
-    grant_access roles: :senior_accountant
-
-    grant_access action: :index, roles: [:secretary, :accountant], if: -> { InvoicesPolicy.new(current_user).can_access?(:index) }
-    def index
-      @invoices = Invoice.all
-      @invoices = @invoices.where("total < 10000") if current_user.has_role?(:accountant)
-      @invoices = @invoices.unpaid if current_user.has_role?(:secretary)
-      # ...
-    end
-
-    grant_access action: :show, roles: :accountant, unless: -> { Invoice.find(params[:id]).total > 10_000 }
-    def show
-      # ...
-    end
-  end
-end
-```
+  # Proc-based conditions
+  grant_access action: :show, roles: :client, if: -> { current_user.company_id == Order.find(params[:id]).company_id }
 
-You can pass a dynamic rule as `if` or `unless` argument. You can pass a symbol (method name) or a proc. Symbols refer to instance methods, and procs are evaluated in the controller at request time.
+  # Dynamic-only rules (no roles required, can be used with custom policies)
+  grant_access action: :index, if: -> { OrdersPolicy.new(current_user).can_access?(:index) }
 
-You can use only dynamic rules without specifying roles if that suits your needs:
+  private
 
-```rb
-class InvoicesController < ApplicationController
-  grant_access action: :index, if: -> { current_user.company == Company.find(params[:company_id]) }
-  def index
-    # ...
+  def company_manager?
+    current_user.manager_of?(Company.find(params[:company_id]))
   end
-end
-```
-
-This allows you to use Rabarber as a policy-based authorization library by calling your own custom policy within a dynamic rule:
 
-```rb
-class InvoicesController < ApplicationController
-  grant_access action: :index, if: -> { InvoicesPolicy.new(current_user).can_access?(:index) }
-  def index
-    # ...
+  def suspended?
+    current_user.suspended?
   end
 end
 ```
 
-## Context / Multi-tenancy
-
-Rabarber supports multi-tenancy through its context feature. This allows you to define and authorize roles and rules within a specific context.
+## Multi-tenancy / Context
 
-Every Rabarber method can accept a context as an additional keyword argument. By default, the context is set to `nil`, meaning the roles are global. Thus, all examples from other sections of this README are valid for global roles. Besides being global, context can also be an instance of an `ActiveRecord` model or a class.
+All Rabarber methods accept a `context` parameter, allowing you to work with roles within specific scopes rather than globally.
 
-E.g., consider a model named `Project`, where each project has its owner and regular members. Roles can be defined like this:
+### Contextual Role Assignment
 
 ```rb
+# Assign roles within a specific model instance
 user.assign_roles(:owner, context: project)
-another_user.assign_roles(:member, context: project)
-```
-
-You can then check roles like this:
+user.assign_roles(:member, context: project)
 
-```rb
-user.has_role?(:owner, context: project)
-another_user.has_role?(:member, context: project)
-```
-
-A role can also be added using a class as a context, e.g., for project admins who can manage all projects:
-
-```rb
+# Assign roles within a model class (e.g., project admin)
 user.assign_roles(:admin, context: Project)
-```
 
-And to check it:
-
-```rb
+# Check contextual roles
+user.has_role?(:owner, context: project)
 user.has_role?(:admin, context: Project)
+
+# Get roles within context
+user.roles(context: project)
+Rabarber::Role.names(context: Project)
 ```
 
-In authorization rules, the context can be used in the same way, but it also can be a proc or a symbol (similar to dynamic rules):
+### Contextual Authorization
 
 ```rb
 class ProjectsController < ApplicationController
+  # Class-based context
   grant_access roles: :admin, context: Project
 
-  grant_access action: :show, roles: :member, context: :project
-  def show
-    # ...
-  end
+  # Instance-based context (method)
+  grant_access action: :show, roles: :member, context: :current_project
 
+  # Instance-based context (proc)
   grant_access action: :update, roles: :owner, context: -> { Project.find(params[:id]) }
-  def update
-    # ...
-  end
 
   private
 
-  def project
-    Project.find(params[:id])
+  def current_project
+    @current_project ||= Project.find(params[:id])
   end
 end
 ```
 
-Role names are scoped by context, i.e. `admin` in a project is different from a global `admin`, or from an `admin` in another project.
-
-If you want to see all the roles assigned to a user within a specific context, you can use:
-
-```rb
-user.roles(context: project)
-```
+### Context Migrations
 
-Or if you want to get all the roles available in a specific context, you can use:
+Handle context changes when models are renamed or removed. These are irreversible data migrations.
 
 ```rb
-Rabarber::Role.names(context: Project)
-```
-
-If a context object (e.g., a project) is deleted, any roles tied to it automatically become irrelevant and are no longer returned by role queries. Rabarber treats them as orphaned and ignores them.
-
-However, if a context class is renamed (e.g., `Project` becomes `Campaign`), an exception will be raised the next time Rabarber attempts to load roles for that class. This is to ensure you explicitly handle the migration, either by migrating existing roles to the new context or by cleaning up old data.
-
-To help with such scenarios, Rabarber provides two helper methods that can be called in migrations:
-
-- `migrate_authorization_context!(old_context, new_context)` - renames a context
-- `delete_authorization_context!(context)` – removes roles tied to a deleted context
-
-These are irreversible data migrations.
-
-## When Unauthorized
-
-By default, Rabarber redirects back on unauthorized access if the request format is HTML (falling back to the root path), and returns a 401 Unauthorized for other formats.
-
-You can customize this behavior by overriding the private `when_unauthorized` method:
-
-```rb
-class ApplicationController < ActionController::Base
-  include Rabarber::Authorization
-
-  with_authorization
-
-  # ...
-
-  private
+# Rename a context class (e.g., when you rename your Project model to Campaign)
+migrate_authorization_context!("Project", "Campaign")
 
-  def when_unauthorized
-    head :not_found # pretend the page doesn't exist
-  end
-end
+# Remove orphaned context data (e.g., when you delete a model entirely)
+delete_authorization_context!("DeletedModel")
 ```
 
-The method can be overridden in different controllers, providing flexibility in handling unauthorized access attempts.
-
-## Skip Authorization
-
-To skip authorization, use `.skip_authorization(options = {})` method:
-
-```rb
-class TicketsController < ApplicationController
-  skip_authorization only: :index
-  # ...
-end
-```
-
-This method accepts the same options as Rails’ `skip_before_action`.
-
 ## View Helpers
 
-Rabarber provides two helpers for use in views: `visible_to(*roles, context: nil, &block)` and `hidden_from(*roles, context: nil, &block)`. To enable them, include `Rabarber::Helpers` in your helper module, typically `ApplicationHelper`.
+Include view helpers in your application:
 
 ```rb
 module ApplicationHelper
   include Rabarber::Helpers
-  # ...
 end
 ```
 
-The usage is straightforward:
+Use conditional rendering based on roles:
 
 ```erb
 <%= visible_to(:admin, :manager) do %>
-  <p>Visible only to admins and managers</p>
+  <div class="admin-panel">
+    <!-- Admin/Manager content -->
+  </div>
 <% end %>
-```
 
-```erb
-<%= hidden_from(:accountant) do %>
-  <p>Accountant cannot see this</p>
+<%= hidden_from(:guest) do %>
+  <div class="member-content">
+    <!-- Content hidden from guests -->
+  </div>
+<% end %>
+
+<!-- With context -->
+<%= visible_to(:owner, context: @project) do %>
+  <button>Delete Project</button>
 <% end %>
 ```
 
-## Problems?
+## Contributing
 
-Facing a problem or want to suggest an enhancement?
+### Getting Help
+Have a question or need assistance? Open a discussion in our [discussions section](https://github.com/brownboxdev/rabarber/discussions) for:
+- Usage questions
+- Implementation guidance
+- Feature suggestions
 
-- **Open a Discussion**: If you have a question, experience difficulties using the gem, or have a suggestion for improvements, feel free to use the Discussions section.
+### Reporting Issues
+Found a bug? Please [create an issue](https://github.com/brownboxdev/rabarber/issues) with:
+- A clear description of the problem
+- Steps to reproduce the issue
+- Your environment details (Rails version, Ruby version, etc.)
 
-Encountered a bug?
+### Contributing Code
+Ready to contribute? You can:
+- Fix bugs by submitting pull requests
+- Improve documentation
+- Add new features (please discuss first in our [discussions section](https://github.com/brownboxdev/rabarber/discussions))
 
-- **Create an Issue**: If you've identified a bug, please create an issue. Be sure to provide detailed information about the problem, including the steps to reproduce it.
-- **Contribute a Solution**: Found a fix for the issue? Feel free to create a pull request with your changes.
+Before contributing, please read the [contributing guidelines](https://github.com/brownboxdev/rabarber/blob/main/CONTRIBUTING.md)
 
-## Contributing
+## License
 
-Before creating an issue or a pull request, please read the [contributing guidelines](https://github.com/brownboxdev/rabarber/blob/main/CONTRIBUTING.md).
+The gem is available as open source under the terms of the [MIT License](https://github.com/brownboxdev/rabarber/blob/main/LICENSE.txt).
 
 ## Code of Conduct
 
@@ -601,7 +392,3 @@ Only the latest major version is supported. Older versions are obsolete and not
 
 [v4.x.x](https://github.com/brownboxdev/rabarber/blob/9353e70281971154d5acd70693620197a132c543/README.md) | [v3.x.x](https://github.com/brownboxdev/rabarber/blob/3bb273de7e342004abc7ef07fa4d0a9a3ce3e249/README.md)
  | [v2.x.x](https://github.com/brownboxdev/rabarber/blob/875b357ea949404ddc3645ad66eddea7ed4e2ee4/README.md) | [v1.x.x](https://github.com/brownboxdev/rabarber/blob/b81428429404e197d70317b763e7b2a21e02c296/README.md)
-
-## License
-
-The gem is available as open source under the terms of the [MIT License](https://github.com/brownboxdev/rabarber/blob/main/LICENSE.txt).

data/lib/rabarber/controllers/concerns/authorization.rb

@@ -9,13 +9,13 @@ module Rabarber
       def with_authorization(options = {})
         before_action :with_authorization, **options
       rescue ArgumentError => e
-        raise Rabarber::Error, e.message
+        raise Rabarber::InvalidArgumentError, e.message
       end
 
       def skip_authorization(options = {})
         skip_before_action :with_authorization, **options
       rescue ArgumentError => e
-        raise Rabarber::Error, e.message
+        raise Rabarber::InvalidArgumentError, e.message
       end
 
       def grant_access(action: nil, roles: nil, context: nil, if: nil, unless: nil)
@@ -39,7 +39,7 @@ module Rabarber
     end
 
     def when_unauthorized
-      request.format.html? ? redirect_back(fallback_location: root_path) : head(:unauthorized)
+      request.format.html? ? redirect_back(fallback_location: root_path) : head(:forbidden)
     end
   end
 end

data/lib/rabarber/models/concerns/has_roles.rb

@@ -40,7 +40,7 @@ module Rabarber
       )
 
       if roles_to_assign.any?
-        delete_roleable_cache(context: processed_context)
+        delete_roleable_cache(contexts: [processed_context])
         rabarber_roles << roles_to_assign
       end
 
@@ -56,13 +56,23 @@ module Rabarber
       )
 
       if roles_to_revoke.any?
-        delete_roleable_cache(context: processed_context)
+        delete_roleable_cache(contexts: [processed_context])
         self.rabarber_roles -= roles_to_revoke
       end
 
       roles(context: processed_context)
     end
 
+    def revoke_all_roles
+      return if rabarber_roles.none?
+
+      contexts = all_roles.keys.map { process_context(_1) }
+
+      rabarber_roles.clear
+
+      delete_roleable_cache(contexts:)
+    end
+
     private
 
     def create_new_roles(role_names, context:)
@@ -78,8 +88,8 @@ module Rabarber
       Rabarber::Input::Context.new(context).process
     end
 
-    def delete_roleable_cache(context:)
-      Rabarber::Core::Cache.delete([roleable_id, context], [roleable_id, :all])
+    def delete_roleable_cache(contexts:)
+      Rabarber::Core::Cache.delete(*contexts.map { [roleable_id, _1] }, [roleable_id, :all])
     end
 
     def roleable_id

data/lib/rabarber/models/role.rb

@@ -4,11 +4,6 @@ module Rabarber
   class Role < ActiveRecord::Base
     self.table_name = "rabarber_roles"
 
-    validates :name, presence: true,
-                     uniqueness: { scope: [:context_type, :context_id] },
-                     format: { with: Rabarber::Input::Role::REGEX },
-                     strict: true
-
     belongs_to :context, polymorphic: true, optional: true
 
     has_and_belongs_to_many :roleables, class_name: Rabarber::Configuration.instance.user_model_name,

data/lib/rabarber/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Rabarber
-  VERSION = "5.0.0"
+  VERSION = "5.1.0"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: rabarber
 version: !ruby/object:Gem::Version
-  version: 5.0.0
+  version: 5.1.0
 platform: ruby
 authors:
 - enjaku4