rabarber 0.1.2 → 0.1.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: d6a4f1f81f8a1bf56e999dcc0fbcce91499e428539fc7a48527080519c37775f
-  data.tar.gz: 9ac2c1a7b2066705cf68d91805af30997bd2c6fc117d3d613fcfbe77cb42b3c6
+  metadata.gz: defa329a94240744ede0911a0d2724a93d5820637614d68c9d4eedd925459951
+  data.tar.gz: ef33ca54c1d80bc2986435eb61462e5a47c37ba7c3d04cdd33a2a8a5d2ce2d73
 SHA512:
-  metadata.gz: 898892e6fb802b65bf5815747ee0f0169b0b678beb0005003d7003b019ff704afa346107db8185c9e1e11de9747a591427262be9ba7221bbc323132c59577a28
-  data.tar.gz: c9dcc16dd51f61d9fe032b4148c8b8f79bfa5656fc2c7ed9d625e7d5ec7cddaf1d7d8b13f163cbd4d1ab6f301082898925cee25a0d0426aa99a24f501141454a
+  metadata.gz: 54a16170222252d4f067686a4c129e61ff92a649504d815e11f76d74e4fb33984cf76eaa048d7b474b4dd93f89f8f816bface0456bdd9a19a6b1b17bbd12a5ae
+  data.tar.gz: fc89759b5cce5e8adc0dbd87aacbba28dd728a89342a72f69ff1a8366d485ec987f716febc005e8e3405d805d51d5e74523abcf830442dfbb120d4a9cb727026

data/.rubocop.yml

@@ -11,6 +11,9 @@ Layout/LineLength:
 Metrics/BlockLength:
   Enabled: false
 
+Naming/PredicateName:
+  Enabled: false
+
 Rails/ApplicationController:
   Exclude:
     - spec/support/controllers.rb

data/CHANGELOG.md

@@ -1,3 +1,12 @@
+## 0.1.4
+
+- Remove `role?` method as unnecessary
+- Update README
+
+## 0.1.3
+
+- Revise and update README for clarity
+
 ## 0.1.2
 
 - Fix check that `Rabarber::HasRoles` can only be included once

data/README.md

@@ -2,11 +2,11 @@
 
 Rabarber is an authorization library primarily designed for use in the web layer of your application, specifically in controllers and views.
 
-Rabarber takes a slightly different approach compared to some popular libraries. Instead of answering, "Who can perform actions on this record?" it focuses on a question: "Who can access this endpoint?" In Rabarber, authorization is expressed not as "A user with role 'editor' can edit a post," but rather as "A user with the role 'editor' can access a post editing endpoint."
+Rabarber takes a slightly different approach compared to some popular libraries. Rabarber focuses on the question: "Who can access this endpoint?". In Rabarber, authorization is expressed not as "A user with the role 'editor' can edit a post," but rather as "A user with the role 'editor' can access a post editing endpoint."
 
-#### Example Usage:
+#### Example of Usage:
 
-Consider a CRM application where users in different roles have distinct access levels. For instance, an accountant role can interact with invoices and orders but cannot access marketing information, while the marketer role has access to marketing-related data.
+Consider a CRM where users with different roles have distinct access levels. For instance, the role 'accountant' can interact with invoices and orders but cannot access marketing information, while the role 'marketer' has access to marketing-related data.
 
 ## Installation
 
@@ -16,13 +16,13 @@ Add the Rabarber gem to your Gemfile:
 gem "rabarber"
 ```
 
-Install the gem: 
+Install the gem:
 
 ```
 bundle install
 ```
 
-Next, generate a migration to create tables for storing roles in the database: 
+Next, generate a migration to create tables for storing roles in the database:
 
 ```
 rails g rabarber:roles
@@ -36,7 +36,7 @@ rails db:migrate
 
 ## Configuration
 
-Seamlessly include Rabarber in your application by adding the following initializer:
+Rabarber can be configured by adding the following code into an initializer:
 
 ```rb
 Rabarber.configure do |config|
@@ -48,12 +48,12 @@ Rabarber.configure do |config|
 end
 ```
 - `current_user_method` must be a symbol representing the method that returns the currently authenticated user. The default value is `:current_user`.
-- `must_have_roles` must be a boolean, determining whether a user with no roles can access endpoints permitted to everyone. The default value is `false` (allowing users without roles to access endpoints permitted for everyone).
-- `when_unauthorized` must be a lambda where you can define your actions when access is not authorized (`controller` is the instance of the controller where the code is executed). By default, the user is redirected back for HTML requests; otherwise, a 401 Unauthorized response is sent.
+- `must_have_roles` must be a boolean determining whether a user with no roles can access endpoints permitted to everyone. The default value is `false` (allowing users without roles to access endpoints permitted to everyone).
+- `when_unauthorized` must be a lambda where you can define your actions when access is not authorized (`controller` is an instance of the controller where the code is executed). By default, the user is redirected back if the request format is HTML; otherwise, a 401 Unauthorized response is sent.
 
 ## Usage
 
-Include the `Rabarber::HasRoles` module in your model representing application users:
+Include `Rabarber::HasRoles` module in your model representing users in your application:
 
 ```rb
 class User < ApplicationRecord
@@ -71,19 +71,26 @@ To assign roles to the user, use:
 ```rb
 user.assign_roles(:accountant, :marketer)
 ```
-By default, the `#assign_roles` method 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 the `create_new: false` argument:
+By default, `#assign_roles` method 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)
 ```
 
+You can also explicitly create new roles simply by using:
+
+```rb
+Rabarber::Role.create(name: "manager")
+```
+The role names are unique.
+
 #### `#revoke_roles`
 
-To revoke roles from the user, use:
+To revoke roles, use:
 
 ```rb
 user.revoke_roles(:accountant, :marketer)
 ```
-If any of the specified roles doesn't exist or the user doesn't have such a role, it will be ignored.
+If any of the specified roles doesn't exist or the user doesn't have the role you want to revoke, it will be ignored.
 
 #### `#has_role?`
 
@@ -97,25 +104,32 @@ It returns `true` if the user has at least one role and `false` otherwise.
 
 #### `#roles`
 
-View all roles assigned to the user:
+To view all the roles assigned to the user, use:
 
 ```rb
 user.roles
 ```
+This will return an array of `Rabarber::Role` objects.
 
-Utilize these methods to manipulate user roles. For example, create a custom UI for managing roles or assign necessary roles during migration or runtime (e.g., when the user is created). Adapt them to fit the requirements of your app.
+If you need the list of role names, use:
 
-If you need to list all the role names, use:
+```rb
+user.roles.names
+```
+
+If you need to list all the role names available in your application, use:
 
 ```rb
 Rabarber::Role.names
 ```
 
+Utilize these methods to manipulate user roles. For example, create a custom UI for managing roles or assign necessary roles during migration or runtime (e.g., when the user is created). Adapt them to fit the requirements of your application.
+
 ---
 
 ### Authorization Rules
 
-Include the `Rabarber::Authorization` module in the controller to which (specifically to it and its children) you want authorization rules to be applied. Typically, it is `ApplicationController`, but it can be any controller.
+Include `Rabarber::Authorization` module into the controller that needs authorization rules to be applied (authorization rules will be applied to the controller and its children). Typically, it is `ApplicationController`, but it can be any controller.
 
 ```rb
 class ApplicationController < ActionController::Base
@@ -123,7 +137,7 @@ class ApplicationController < ActionController::Base
   ...
 end
 ```
-This adds the `.grant_access` method to the controller and its children. This method allows you to define the access rules.
+This adds `.grant_access` method to the controller and its children. This method allows you to define the authorization rules.
 
 The most basic usage of the method is as follows:
 
@@ -140,13 +154,13 @@ class InvoicesController < ApplicationController
   end
 end
 ```
-This grants access to the `index` action for users with the `accountant` or `admin` role, and access to the `delete` action for only `admin` users.
+This grants access to `index` action for users with `accountant` or `admin` role, and access to `delete` action for `admin` users only.
 
-You can also define controller-wide rules (without the `action` argument):
+You can also define controller-wide rules (without `action` argument):
 
 ```rb
 class Crm::BaseController < ApplicationController
-  grant_access roles: :admin, :manager
+  grant_access roles: [:admin, :manager]
 
   grant_access action: :dashboard, roles: :marketer
   def dashboard
@@ -154,7 +168,7 @@ class Crm::BaseController < ApplicationController
   end
 end
 
-class InvoicesController < Crm::BaseControlle
+class Crm::InvoicesController < Crm::BaseController
   grant_access roles: :accountant
   def index
     ...
@@ -165,9 +179,9 @@ class InvoicesController < Crm::BaseControlle
   end
 end
 ```
-This means that `admin` and `manager` have access to all actions inside `Crm::BaseController` and its children, while the `accountant` role has access only to actions in `InvoicesController` and its possible children. Users with the `marketer` role can see only the dashboard in this example.
+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 (as well as actions) can be omitted:
+Roles can also be omitted:
 
 ```rb
 class OrdersController < ApplicationController
@@ -183,9 +197,9 @@ class InvoicesController < ApplicationController
 end
 ```
 
-This allows everyone to access `OrdersController` and its children and the `index` action in `InvoicesController`.
+This allows everyone to access `OrdersController` and its children and `index` action in `InvoicesController`.
 
-If you've set the `must_have_roles` setting to `true`, then only the users with at least one role can have access. This setting can be useful if your requirements are so that users without roles are not allowed to see anything.
+If you've set `must_have_roles` setting to `true`, then, only the users with at least one role can have access. This setting can be useful if your requirements are such that users without roles are not allowed to see anything.
 
 For more complex rules, Rabarber provides the following:
 
@@ -202,13 +216,13 @@ class OrdersController < ApplicationController
 end
 
 class InvoicesController < ApplicationController
-  grant_access action: :index, roles: :accountant, if: -> { current_user.passed_probationary_period? }
+  grant_access action: :index, roles: :accountant, if: -> { current_user.passed_probation_period? }
   def index
     ...
   end
 end
 ```
-You can pass a custom rule as an `if` argument. It can be a symbol (the method with the same name will be called) or a lambda.
+You can pass a custom rule as `if` argument. It can be a symbol (the method with the same name will be called) or a lambda.
 
 Rules defined in children don't override parent rules but rather add to them:
 ```rb
@@ -217,12 +231,12 @@ class Crm::BaseController < ApplicationController
   ...
 end
 
-class InvoicesController < Crm::BaseControlle
+class Crm::InvoicesController < Crm::BaseController
   grant_access roles: :accountant
   ...
 end
 ```
-This means that `InvoicesController` is still accessible to `admin` but is also accessible to `accountant`.
+This means that `Crm::InvoicesController` is still accessible to `admin` but is also accessible to `accountant`.
 
 ---
 
@@ -244,9 +258,9 @@ Rabarber also provides a couple of helpers that can be used in views: `visible_t
 
 ## Problems?
 
-Encountered a bug or facing a problem? 
+Encountered a bug or facing a problem?
 
-- **Create an Issue**: If you've identified a problem or have a feature request, please create an issue on the gem's GitHub repository. Be sure to provide detailed information about the problem, including steps to reproduce it.
+- **Create an Issue**: If you've identified a problem or have a feature request, please create an issue on the gem's GitHub repository. Be sure to provide detailed information about the problem, including the steps to reproduce it.
 - **Contribute a Solution**: Found a fix for the issue or want to contribute to the project? Feel free to create a pull request with your changes.
 
 ## License

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

@@ -5,7 +5,7 @@ module Rabarber
     extend ActiveSupport::Concern
 
     included do
-      before_action :check_permissions
+      before_action :verify_access
     end
 
     class_methods do
@@ -16,7 +16,7 @@ module Rabarber
 
     private
 
-    def check_permissions
+    def verify_access
       return if Permissions.access_granted?(
         send(::Rabarber::Configuration.instance.current_user_method).roles.names, self.class, action_name.to_sym, self
       )

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

@@ -12,11 +12,9 @@ module Rabarber
       has_and_belongs_to_many :roles, class_name: "Rabarber::Role",
                                       foreign_key: "roleable_id",
                                       join_table: "rabarber_roles_roleables"
-
-      alias_method :has_role?, :role?
     end
 
-    def role?(*role_names)
+    def has_role?(*role_names)
       unless role_names.all? { |arg| arg.is_a?(Symbol) || arg.is_a?(String) }
         raise(ArgumentError, "Role names must be symbols or strings")
       end

data/lib/rabarber/version.rb

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

metadata

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