Accessing Rails controller methods from Avo Actions

[its-fern]

👋 I've been running into this odd issue that I can't figure out. I came up with a work-around but I'm wondering if there's a better way.

We're migrating to Avo from another admin dashboard. One capability that we had added in the past is to allow admin users to impersonate others. We use the Pretender gem for this.

Playing around with Avo, it seemed like defining an Action would be the move here, but that's when I started experiencing issues with accessing methods defined in the base controller within Actions.

A simple example is as follows:

# Gemfile
gem "pretender", "~> 0.6.0"

# app/controllers/concerns/admin/impersonation.rb
module Admin::Impersonation
  extend ActiveSupport::Concern

  included do
    impersonates :user
  end
end

# config/initializers/avo.rb
Rails.configuration.to_prepare do
  Avo::ApplicationController.include Admin::Impersonation
end

# app/avo/actions/impersonate_user.rb
class Avo::Actions::ImpersonateUser < Avo::BaseAction
  self.name = "Impersonate User"
  
  def handle(query:, fields:, current_user:, resource:, **args)
    # This fails with NoMethodError
    impersonate_user(resource.record)
    succeed "Impersonating #{resource.record.name}"
  end
end

The error I get is:

NoMethodError: undefined method 'impersonate_user' for an instance of Avo::Actions::ImpersonateUser

After debugging, I discovered that Avo actions don't have access to controller-specific methods defined through these concerns.

My workaround worked out since the pretender gem is simply setting a key on the session:

class Avo::Actions::ImpersonateUser < Avo::BaseAction
  self.name = "Impersonate User"
  
  def handle(query:, fields:, current_user:, resource:, **args)
    impersonate_user(resource.record)
    succeed "Now impersonating #{resource.record.name}"
  end
  
  private
  
  def impersonate_user(user)
    Avo::Current.request.session[:pretender_user_id] = user.id
  end
end

My question here is: Am I missing something with the way actions are architected?

[Paul-Bob]

Hi @its-fern, thank you for the detailed explanation.

My question here is: Am I missing something with the way actions are architected?

No, you interpreted the actions architecture correctly. The handle method is heavily based on a pre-built DSL and doesn't run in the controller's context. This was an early architectural decision.

We received feedback about the need for the handle method to run within the controller context. That's why, while working on the Avo 4 forms feature, we made sure the handle method there is executed in the controller context. We haven't built much DSL around it yet, since at the controller level, each developer has full control over business logic and the response. Not directly relevant here, but I wanted to share some background.

---

Your workaround works and seems legit. I'd take a different approach that I consider more time-proof, since your workaround dips into session internals a bit.

Here's how I set up pretender in our audit logging demo app:

1. Created a concern: https://github.com/avo-hq/audit_logging.avodemo.com/blob/main/app/controllers/concerns/use_pretender.rb#L0-L1
2. Included it in Avo controllers: https://github.com/avo-hq/audit_logging.avodemo.com/blob/main/config/initializers/avo.rb#L165
3. Used Avo route helpers to redirect to the impersonate path: https://github.com/avo-hq/audit_logging.avodemo.com/blob/main/app/avo/actions/impersonate.rb#L11

Final result: https://audit-logging.avodemo.com/avo/resources/users

I implemented this a while ago, so it's possible I missed a step. Let me know if it doesn't work for you right away.

I also added a guide idea for "how to use Pretender" to our guide ideas list here: avo-hq/docs.avohq.io#373.

---

We're migrating to Avo from another admin dashboard.

I'm curious, how it's going beside this? Any rough edges or surprises so far?

[its-fern]

Hey @Paul-Bob - appreciate the prompt reply!

Sounds good re Avo 4 - seems like there's some cool stuff coming there. Looking forward to it!

On the approach you took in the demo app, the one nit I have is that starting the impersonation is done through a GET request (within the action it redirects_to avo.impersonation_path) while we use a POST request to start the impersonation process - so the redirect_to wouldn't work for us. For now we will likely keep the current (albeit kinda gross) implementation of setting the session key within the action.

I'm curious, how it's going beside this? Any rough edges or surprises so far?

So far so good! A few things to note so far, nothing critical just things that stood out:

1. Using coding agent tools that suggest features that we did not have access to due to them being pro/advanced/enterprise features. I initially started with the Community version and spent a bit of time trying to figure out why authorization wasn't working the way I expected. Once I took another look at the documentation, it was obvious that authorization was a Pro version feature. Very much a "just read the manual bro" moment. Might be worth adding a banner or something to the app if the authorization features are being used without a proper license key?
2. We use vite to manage our JS and CSS assets (Stimulus + Tailwind), it took some time to figure this out, but not a show stopper. We added another entrypoint just for the admin dashboard so that it loads any custom stimulus controllers we've defined.

Otherwise we are very excited to continue here. There are a ton of features that I think can really elevate the admin experience for our CX team.

[Paul-Bob]

For now we will likely keep the current (albeit kinda gross) implementation of setting the session key within the action.

Got it

Might be worth adding a banner or something to the app if the authorization features are being used without a proper license key?

Totally, we're tracking this developer experience enhancement on this task #3745

Otherwise we are very excited to continue here. There are a ton of features that I think can really elevate the admin experience for our CX team.

Awesome, thank you for all the feedback!