rabarber 4.1.4 → 5.1.0

data/README.md

@@ -1,61 +1,40 @@
-# 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/enjaku4/rabarber/actions/workflows/ci.yml/badge.svg)](https://github.com/enjaku4/rabarber/actions/workflows/ci.yml)
+[![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, supports multi-tenancy and comes with audit logging for enhanced security.
+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. Such authorization rules can be easily defined 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)
-  - [Roles](#roles)
-  - [Authorization Rules](#authorization-rules)
-  - [Dynamic Authorization Rules](#dynamic-authorization-rules)
-  - [Context / Multi-tenancy](#context--multi-tenancy)
-  - [When Unauthorized](#when-unauthorized)
-  - [Skip Authorization](#skip-authorization)
+  - [Role Management](#role-management)
+  - [User Role Methods](#user-role-methods)
+  - [Controller Authorization](#controller-authorization)
+  - [Dynamic Rules](#dynamic-rules)
+  - [Multi-tenancy / Context](#multi-tenancy--context)
   - [View Helpers](#view-helpers)
-  - [Audit Trail](#audit-trail)
+
 
 **Community Resources:**
-  - [Problems?](#problems)
   - [Contributing](#contributing)
-  - [Code of Conduct](#code-of-conduct)
-
-**Legal:**
   - [License](#license)
+  - [Code of Conduct](#code-of-conduct)
+  - [Old Versions](#old-versions)
 
 ## Installation
 
-Add the Rabarber gem to your Gemfile:
+Add Rabarber to your Gemfile:
 
 ```rb
 gem "rabarber"
@@ -67,19 +46,17 @@ Install the gem:
 bundle install
 ```
 
-Next, generate a migration to create tables for storing roles in the database. Make sure to specify the table name of the model representing users in your application as an argument. For instance, if the table name 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 to the generator:
+# 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 to apply the changes to the database:
+Run the migration:
 
 ```shell
 rails db:migrate
@@ -87,493 +64,331 @@ rails db:migrate
 
 ## Configuration
 
-If specific customization is required, Rabarber can be configured by using `.configure` method in an initializer:
+Configure Rabarber in an initializer if customization is needed:
 
 ```rb
 Rabarber.configure do |config|
-  config.audit_trail_enabled = true
-  config.cache_enabled = true
-  config.current_user_method = :current_user
-  config.must_have_roles = false
-end
-```
-
-- `audit_trail_enabled` determines whether the audit trail functionality is enabled. The audit trail is enabled by default.
-- `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` represents the method that returns the currently authenticated user. The default value is `:current_user`.
-- `must_have_roles` determines whether a user with no roles can access endpoints permitted to everyone. The default value is `false` (allowing users without roles to access such endpoints).
-
-## Roles
-
-Include `Rabarber::HasRoles` module in your model representing users in your application:
-
-```rb
-class User < ApplicationRecord
-  include Rabarber::HasRoles
-  # ...
+  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
 ```
 
-This adds the following methods:
+To clear the role cache manually:
 
-**`#assign_roles(*roles, context: nil, create_new: true)`**
-
-To assign roles, use:
-
-```rb
-user.assign_roles(:accountant, :marketer)
-```
-By default, it will automatically create any roles that don't exist. If you want to assign only existing roles and prevent the creation of new ones, use the method with `create_new: false` argument:
 ```rb
-user.assign_roles(:accountant, :marketer, create_new: false)
+Rabarber::Cache.clear
 ```
-The method returns an array of roles assigned to the user.
 
-**`#revoke_roles(*roles, context: nil)`**
+## Role Management
 
-To revoke roles, use:
+### Direct Role Operations
 
 ```rb
-user.revoke_roles(:accountant, :marketer)
-```
-If the user doesn't have the role you want to revoke, it will be ignored.
+# Create a new role
+Rabarber::Role.add(:admin)
 
-The method returns an array of roles assigned to the user.
+# Rename a role
+Rabarber::Role.rename(:admin, :administrator)
+Rabarber::Role.rename(:admin, :administrator, force: true) # Force if role is assigned to users
 
-**`#has_role?(*roles, context: nil)`**
+# Remove a role
+Rabarber::Role.remove(:admin)
+Rabarber::Role.remove(:admin, force: true) # Force if role is assigned to users
 
-To check whether the user has a role, use:
+# List available roles
+Rabarber::Role.names
+Rabarber::Role.all_names # All roles grouped by context
 
-```rb
-user.has_role?(:accountant, :marketer)
+# Get users assigned to a role
+Rabarber::Role.assignees(:admin)
 ```
 
-It returns `true` if the user has at least one role and `false` otherwise.
+## User Role Methods
 
-**`#roles(context: nil)`**
+Your user model is automatically augmented with role management methods:
 
-To get the list of roles assigned to the user, use:
+### Role Assignment
 
 ```rb
-user.roles
-```
+# Assign roles (creates roles if they don't exist)
+user.assign_roles(:accountant, :manager)
 
-**`#all_roles`**
+# Assign only existing roles
+user.assign_roles(:accountant, :manager, create_new: false)
 
-To get all roles assigned to the user, grouped by context, use:
+# Revoke specific roles
+user.revoke_roles(:accountant, :manager)
 
-```rb
-user.all_roles
+# Revoke all roles
+user.revoke_all_roles
 ```
 
----
-
-To manipulate roles directly, you can use `Rabarber::Role` methods:
-
-**`.add(role_name, context: nil)`**
-
-To add a new role, use:
+### Role Queries
 
 ```rb
-Rabarber::Role.add(:admin)
-```
+# Check if user has any of the specified roles
+user.has_role?(:accountant, :manager)
 
-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:
+# Get user's roles
+user.roles
 
-```rb
-Rabarber::Role.rename(:admin, :administrator)
+# Get all roles grouped by context
+user.all_roles
 ```
-The first argument is the old name, and the second argument is the new name. This will rename the role and return `true`. If the role with a new name already exists, it will return `false`.
 
-The method won't rename the role and will return `false` if it is assigned to any user. To force the rename, use the method with `force: true` argument:
-```rb
-Rabarber::Role.rename(:admin, :administrator, force: true)
-```
+## Controller Authorization
 
-**`.remove(role_name, context: nil, force: false)`**
+### Basic Setup
 
-To remove a role, use:
+Include the authorization module and configure protection:
 
 ```rb
-Rabarber::Role.remove(:admin)
-```
-
-This will remove the role and return `true`. If the role doesn't exist, it will return `false`.
-
-The method won't remove the role and will return `false` if it is assigned to any user. To force the removal, use the method with `force: true` argument:
-```rb
-Rabarber::Role.remove(:admin, force: true)
-```
-
-**`.names(context: nil)`**
+class ApplicationController < ActionController::Base
+  include Rabarber::Authorization
 
-If you need to list the roles available in your application, use:
+  with_authorization # Enable authorization for all actions
+end
 
-```rb
-Rabarber::Role.names
+class InvoicesController < ApplicationController
+  with_authorization only: [:update, :destroy] # Selective authorization
+end
 ```
 
-**`.all_names`**
-
-If you need list all roles available in your application, grouped by context, use:
-
-```rb
-Rabarber::Role.all_names
-```
+Authorization requires an authenticated user.
 
-**`.assignees(role_name, context: nil)`**
+### Skip Authorization
 
-To get all the users to whom the role is assigned, use:
+You can also selectively skip authorization:
 
 ```rb
-Rabarber::Role.assignees(:admin)
+class TicketsController < ApplicationController
+  skip_authorization except: [:create, :update, :destroy]
+end
 ```
 
-## Authorization Rules
+### Authorization Rules
 
-Include `Rabarber::Authorization` module into the controller that needs authorization rules to be applied. Typically, it is `ApplicationController`, but it can be any controller of your choice.
+Define access rules using `grant_access`:
 
 ```rb
-class ApplicationController < ActionController::Base
-  include Rabarber::Authorization
-  # ...
-end
-```
-This adds `.grant_access(action: nil, roles: nil, context: nil, if: nil, unless: nil)` method which allows you to define the authorization rules.
+class TicketsController < ApplicationController
+  # Controller-wide access
+  grant_access roles: :admin
 
-The most basic usage of the method is as follows:
+  # Action-specific access
+  grant_access action: :index, roles: [:manager, :support]
+  def index
+    # Accessible to admin, manager, and support roles
+  end
 
-```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
+  grant_access action: :destroy, roles: :admin
+  def destroy
+    # Accessible to admin role only
   end
 end
 ```
-This grants access to `index` action for users with `accountant` or `admin` role, and access to `destroy` action for `admin` users only.
 
-You can also define controller-wide rules (without `action` argument):
+### Additive Rules
+
+Rules are additive across inheritance chains and for the same actions:
 
 ```rb
-module Crm
-  class BaseController < ApplicationController
-    grant_access roles: [:admin, :manager]
-
-    grant_access action: :dashboard, roles: :marketer
-    def dashboard
-      # ...
-    end
-  end
+class BaseController < ApplicationController
+  grant_access roles: :admin # Admin can access everything
 end
 
-module Crm
-  class InvoicesController < Crm::BaseController
-    grant_access roles: :accountant
-    def index
-      # ...
-    end
+class InvoicesController < BaseController
+  grant_access roles: :accountant # Accountant can also access InvoicesController (along with admin)
 
-    def delete
-      # ...
-    end
-  end
+  grant_access action: :index, roles: :manager
+  grant_access action: :index, roles: :supervisor
+  # Index is accessible to admin, accountant, manager, and supervisor
 end
 ```
-This means that `admin` and `manager` have access to all the actions inside `Crm::BaseController` and its children, while `accountant` role has access only to the actions in `Crm::InvoicesController` and its possible children. Users with `marketer` role can only see the dashboard in this example.
 
-Roles can also be omitted:
+### Unrestricted Access
+
+Omit roles to allow unrestricted access:
 
 ```rb
-class OrdersController < ApplicationController
-  grant_access
-  # ...
+class UnrestrictedController < ApplicationController
+  grant_access # Allow all users
 end
 
-class InvoicesController < ApplicationController
-  grant_access action: :index
-  def index
-    # ...
-  end
+class MixedController < ApplicationController
+  grant_access action: :index # Unrestricted index action
+  grant_access action: :show, roles: :member # Restricted show action
 end
 ```
 
-This allows everyone to access `OrdersController` and its children and also `index` action in `InvoicesController`.
+### Custom Unauthorized Handling
 
-If you've set `must_have_roles` setting to `true`, then only the users with at least one role can gain access. This setting can be useful if your requirements are such that users without roles are not allowed to access anything.
+Override `when_unauthorized` method to customize unauthorized access behavior:
 
-Also keep in mind that rules defined in child classes don't override parent rules but rather add to them:
 ```rb
-module Crm
-  class BaseController < ApplicationController
-    grant_access roles: :admin
-  # ...
-  end
-end
+class ApplicationController < ActionController::Base
+  include Rabarber::Authorization
 
-module Crm
-  class InvoicesController < Crm::BaseController
-    grant_access roles: :accountant
-  # ...
-  end
-end
-```
-This means that `Crm::InvoicesController` is still accessible to `admin` but is also accessible to `accountant`.
+  with_authorization
 
-This applies as well to multiple rules defined for the same controller or action:
-```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
+  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 Authorization Rules
+## Dynamic Rules
 
-For more complex cases, Rabarber provides dynamic 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
+class OrdersController < ApplicationController
+  # Method-based conditions
+  grant_access roles: :manager, if: :company_manager?, unless: :suspended?
 
-    private
+  # Proc-based conditions
+  grant_access action: :show, roles: :client, if: -> { current_user.company_id == Order.find(params[:id]).company_id }
 
-    def company_manager?
-      Company.find(params[:company_id]).manager == current_user
-    end
+  # Dynamic-only rules (no roles required, can be used with custom policies)
+  grant_access action: :index, if: -> { OrdersPolicy.new(current_user).can_access?(:index) }
 
-    def fired?
-      current_user.fired?
-    end
-  end
-end
+  private
 
-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
+  def company_manager?
+    current_user.manager_of?(Company.find(params[:company_id]))
   end
-end
-```
-You can pass a dynamic rule as `if` or `unless` argument. It can be a symbol, in which case the method with that name will be called, or alternatively it can be a proc that will be executed within the context of the controller instance at request time.
 
-You can use only dynamic rules without specifying roles if that suits your needs:
-```rb
-class InvoicesController < ApplicationController
-  grant_access action: :index, if: -> { current_user.company == Company.find(params[:company_id]) }
-  def index
-    # ...
-  end
-end
-```
-This basically 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 by providing a 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. Apart from being global, the context can be an instance of 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)
-```
-
-Then the roles can be verified:
+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 then it can also be verified:
-
-```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
 ```
 
-It's important to note that role names are not unique globally but are unique within the scope of their context. E.g., `user.assign_roles(:admin, context: Project)` and `user.assign_roles(:admin)` assign different roles to the user. The same as `Rabarber::Role.add(:admin, context: Project)` and `Rabarber::Role.add(:admin)` create different roles.
-
-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)
-```
-
-## When Unauthorized
-
-By default, in the event of an unauthorized attempt, Rabarber redirects the user back if the request format is HTML (with fallback to the root path), and returns a 401 (Unauthorized) status code otherwise.
+# Rename a context class (e.g., when you rename your Project model to Campaign)
+migrate_authorization_context!("Project", "Campaign")
 
-This behavior can be customized by overriding private `when_unauthorized` method:
-
-```rb
-class ApplicationController < ActionController::Base
-  include Rabarber::Authorization
-
-  # ...
-
-  private
-
-  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 `skip_before_action` method in Rails.
-
 ## View Helpers
 
-Rabarber also provides a couple of helpers that can be used in views: `visible_to(*roles, context: nil, &block)` and `hidden_from(*roles, context: nil, &block)`. To use them, simply include `Rabarber::Helpers` in the desired helper. Usually it is `ApplicationHelper`, but it can be any helper of your choice.
+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 %>
-```
-
-## Audit Trail
-
-Rabarber supports audit trail, which provides a record of user access control activity. This feature logs the following events:
 
-- Role assignments to users
-- Role revocations from users
-- Unauthorized access attempts
-
-The logs are written to the file `log/rabarber_audit.log` unless the `audit_trail_enabled` configuration option is set to `false`.
+<!-- 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/enjaku4/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
 
-Everyone interacting in the Rabarber project is expected to follow the [code of conduct](https://github.com/enjaku4/rabarber/blob/main/CODE_OF_CONDUCT.md).
+Everyone interacting in the Rabarber project is expected to follow the [code of conduct](https://github.com/brownboxdev/rabarber/blob/main/CODE_OF_CONDUCT.md).
 
-## License
+## Old Versions
+
+Only the latest major version is supported. Older versions are obsolete and not maintained, but their READMEs are available here for reference:
 
-The gem is available as open source under the terms of the [MIT License](https://github.com/enjaku4/rabarber/blob/main/LICENSE.txt).
+[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)