Migration guide to version 5.0.0

[enjaku4]

Rabarber v5.0.0 includes several breaking changes and cleanups. This guide helps you migrate your app from Rabarber v3.x.x or v4.x.x.

If you’re new to Rabarber, simply install the latest version and follow the README instructions.

1. with_authorization method

Previously, including Rabarber::Authorization module in a controller would automatically register authorization checks.

Now, authorization must be enabled explicitly using with_authorization method. This provides more granular control over where authorization is applied.

For example, if you previously had:

class ApplicationController < ActionController::Base
  include Rabarber::Authorization

  # ...
end

Update it to:

class ApplicationController < ActionController::Base
  include Rabarber::Authorization

  with_authorization

  # ...
end

Make sure the user is authenticated before authorization checks are performed, as they rely on a current user being present.

2. user_model_name configuration option

The user_model_name option has been introduced to let you specify the name of your user model.

Remove the Rabarber::HasRoles module from your user model. If your model isn’t named User, set user_model_name in your configuration, for example:

Rabarber.configure do |config|
  config.user_model_name = "Client"
end

If your model is User, just remove the module and everything will continue working as before.

3. must_have_roles configuration option

This option has been removed. If you were using it, delete it from your configuration.

It was originally intended for a niche case: when a user without any roles tries to access an unrestricted endpoint (i.e. grant_access is called without specifying roles). Since this scenario is rare and the option caused more confusion than value, it has been removed to simplify the API.

If you still need to enforce such behavior, you can replicate it for example using dynamic authorization rules:

class InvoicesController < ApplicationController
  # only allow access if the user has at least one role
  grant_access action: :index, if: -> { current_user.all_roles.any? }
  def index
    # ...
  end
end

4. Audit trail

The audit trail feature has been removed. If you were using it, remove the audit_trail_enabled option from your configuration.

Originally, it was meant to log role assignments, revocations, and unauthorized access. However, since it couldn’t track who performed the actions, its value was limited and it added unnecessary complexity to the codebase.

If you still need this kind of logging, implement it directly in your application, for example by creating your own wrappers which include logging around role changing methods. It’s straightforward and gives you full control over what gets recorded and how.