PermissionSettings - Changelog

PermissionSettings allows to dynamically set, retrieve and check permissions of your resource model. Under the hood it uses Rails Settings gem for storing settings in database. Main idea is to store permissions in yaml files that can be divided by resource models and roles. It alos allows to change permissions without restarting the application that gives you more flexibility in build a permissions system.

Tested with ruby:

• 3.0.2

Requirements

• Rails 6.1 or newer (including Rails 7.0)

Installation

Include the gem in your Gemfile and run bundle to install it:

gem 'permission_settings', '~> 0.1.0'

Generate and run the migration to create the settings table that is used to store the permissions:

rails g rails_settings:migration
rails db:migrate

Usage

Configuration

You can configure the gem by calling PermissionSettings.configure method in an initializer:

# config/initializers/permission_settings.rb

PermissionSettings.configure do |config|
  config.permissions_dir_path = 'config/permissions'
  config.role_access_method = :role
end

• permissions_dir_path - configuration option for setting path to permissions directory
• role_access_method - configuration option for setting method name to access role of the resource instance

You can create different yaml files for different resource models to keep permissions separated. by default it looks for yaml files in config/permissions directory.

Permissions file structure

Gem will load permissions from yaml files into database on application start.

The permissions file should be a yaml file and should be the same as the name of the resource model.

For example, if you have a User model, you can create a user.yml file in config/permissions directory with the following structure:

# config/permissions/person.yml

admin:
  notifications:
    read: true
    create: true
    edit: true
    delete: true

manager:
  notifications:
    read: true
    create: false
    edit: false
    delete: false

In this file we should divided permissions into roles. If not following this structure gem won't find permissions that are defined for a specific role of that calling instance. If you experience a PersistentSettings::NotFoundError error, please check if you have defined permissions for that role inside the permissions file of resource model.

Connecting permissions to the resource and calling model

To connect permissions to the resource model you need just to include PersmissionSettings module in the model class:

Calling model:

class User < ApplicationRecord
  include PermissionSettings
end

Resource model:

class Person < ApplicationRecord
  include PermissionSettings
end

In order to check permissions of the resource instance you need to pass it as a named argument resource to the #can? method.

Take into account that the resource model should have a role field or method that returns a role name of the calling instance or you can configure the gem to use another method name by setting role_access_method configuration option.

Checking permissions

You can check permissions of the resource instance by calling #can? method:

user = User.first # => #<User id: 1, name: "John", role: "manager">
person = Person.last # => #<Person id: 2, name: "Jane", role: "client">
user.can?(:read, :notifications, resource: person) # => true

Method can? accepts 2 arguments:

• *permission_keys - this keys will be used to find permissions in the settings. It can be a string or an array of strings. Required argument.
• *resource - Named argument resource. Instance towards which the permissions will be checked. Required argument.

Accessing permissions

You can also access permissions of the resource or calling instance by calling #settings method:

person = Person.last # => #<Person id: 2, name: "Jane", role: "client">
person.permissions[:admin][:notifications][:read] # => false

More about settings you can read in Rails Settings gem documentation.

Dynamic settings

You can override default settings by calling #has_settings method in the resource model class:

custom_permissions = {
  admin: {
    notifications: {
      read: false,
      create: false,
      edit: false,
      delete: false
    }
  }
}
admin = User.first # => #<User id: 1, name: "John", role: "admin">
person = Person.last # => #<User id: 2, name: "Jane", role: "client">

admin.can?(:read, :notifications, resource: person) # => true

person.settings(PermissionSettings.configuration.scope_name).update(custom_permissions)

admin.can?(:read, :notifications, resource: person) # => false

If you will unset your custom settings, default settings will be used:

custom_permissions = {
  admin: {
    notifications: {
      read: false,
      create: false,
      edit: false,
      delete: false
    }
  }
}

admin = User.first # => #<User id: 1, name: "John", role: "admin">
person = Person.last # => #<User id: 2, name: "Jane", role: "client">

policy_scope = PermissionSettings.configuration.scope_name(User)
person.settings(policy_scope).update(custom_permissions)

admin.can?(:read, :notifications, resource: person) # => false

person.settings(policy_scope).update({ admin: { notifications: nil } })

admin.can?(:read, :notifications, resource: person) # => true

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and the created tag, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at Permission Settings. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the code of conduct.

License

The gem is available as open source under the terms of the MIT License.

Code of Conduct

Everyone interacting in the PermissionSettings project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.