In Ruby, can you decide from a main method to return or continue when calling a submethod?

Question

I'm using Pundit gem for my authorization classes, where each controller action is checked against the model policy, to see if action is allowed by the user.

These methods are sometimes becoming quite bloated and unreadable, because I'm checking quite some stuff for some objects.

Now I'm thinking to refactor those methods, and place every "validation" in it's own method:

Previous:

class PostPolicy < ApplicationPolicy

 def update
   return true if @user.has_role? :admin
   return true if @object.owner == user
   return true if 'some other reason'
   
   false
 end
end

Now ideally, I want to refactor this in something like:

class PostPolicy < ApplicationPolicy

 def update
   allow_if_user_is_admin
   allow_if_user_owns_record
   allow_for_some_other_reason
   
   false
 end

 private

 def allow_if_user_is_admin
  # this would go in the parent class, as the logic is the same for other objects
  return true if @user.has_role? :admin
 end
end

The problem now is, that the mane update method will keep on going, even if the user is admin, as there's no return. If I would inlcude a return, then the other methods will never be evalutaed. Is there a way in ruby to do kind of a "superreturn", so that when the user is an admin, the main update method would stop evaluting?

Thanks!

Answer 1

Given your example and this comment: "...no native way to do kind of a 'super return' in Ruby? It feels like kind of a "raise" but then with a positive outcome... could I use that perhaps?".

While there are usually other ways to solve the issue that could be considered "more idiomatic", ruby does have a Kernel#throw and Kernel#catch implementation that can be very useful for control flow when navigating through numerous and possibly disparate methods and operations.

The throw and corresponding catch will short circuit the result of the block which appears to be the syntax you are looking for.

VERY Basic Example:

class PostPolicy 
  def initialize(n) 
    @n = n 
  end
  def update
    catch(:fail) do
      stop_bad_actor!
      catch(:success) do 
        allow_if_user_is_admin
        allow_if_user_owns_record
        stop_bad_actor!(2)
        allow_for_some_other_reason
        false
      end 
    end
  end

 private

  def allow_if_user_is_admin
   puts "Is User Admin?"
   throw(:success, true) if @n == 1
  end

  def allow_if_user_owns_record
    puts "Is User Owner?"
    throw(:success,true) if @n == 2
  end 

  def allow_for_some_other_reason
    puts "Is User Special?"
    throw(:success,true) if @n == 3
  end 
  
  def stop_bad_actor!(m=1)
    puts "Is a Bad Actor?"
    throw(:fail, false) if @n == 6 || @n ** m == 64
  end
end

Example Output:

PostPolicy.new(1).update 
# Is a Bad Actor?
# Is User Admin?
#=> true
PostPolicy.new(2).update 
# Is a Bad Actor?
# Is User Admin?
# Is User Owner?
#=> true
PostPolicy.new(3).update 
# Is a Bad Actor?
# Is User Admin?
# Is User Owner?
# Is a Bad Actor?
# Is User Special?
#=> true
PostPolicy.new(4).update 
# Is a Bad Actor?
# Is User Admin?
# Is User Owner?
# Is a Bad Actor?
# Is User Special?
#=> false
PostPolicy.new(6).update 
# Is a Bad Actor?
#=> false
PostPolicy.new(8).update 
# Is a Bad Actor?
# Is User Admin?
# Is User Owner?
# Is a Bad Actor?
#=> false

Answer 2

What you can do is chain && operators.

As soon as one is false, ruby will not evaluate the others (And the update method will return false).

class PostPolicy < ApplicationPolicy

 def update
   allow_if_user_is_admin &&
     allow_if_user_owns_record &&
     allow_for_some_other_reason &&
 end

 private

 def allow_if_user_is_admin
  # this would go in the parent class, as the logic is the same for other objects
  return true if @user.has_role? :admin
 end
end

Answer 3

It seems that this would achieve your aim and be more idiomatic:

class PostPolicy < ApplicationPolicy

  def update
    user_has_admin_role? ||
      user_owns_object? ||
      some_other_reason?
  end

  private
  
  def user_has_admin_role?
    @user.has_role? :admin
  end

  def user_owns_object?
    @object.owner == user
  end

  def some_other_reason?
    'some other reason'
  end
end

Answer 4

You can short-circuit boolean syntax, there me be cases where long chaining would look like bad style, here's an alternative, but basically same idea using Enumerable#all? See this answer for how it short-circuits

class PostPolicy < ApplicationPolicy

  def update
    deny?
  end
  
  private
  
  def deny?
    [ 
      user_is_admin?,
      user_owns_record,
      allow_for_some_other_reason?,
      thing1?,
      thing2? 
    ].any?
  end

  def user_is_admin?
    @user.has_role? :admin
  end

  def user_owns_record?
   @user.owns_record?
  end

  def allow_for_some_other_reason?
    @user.has_cheezebuerger?
  end

  def thing1?
    @user.thing1
  end

  def thing2?
    @user.thing2
  end
end