Issues with has_many relation for STI model

[sandraa-nestor]

Describe the bug

STI model
class Entities::System < Entity with relation has_many :bank_accounts
Bank account model
class BankAccount < ApplicationRecord with belongs_to :system_entity, class_name: "Entities::System"

1. Association policies on STI models are ignored. Cannot hide Attach bank account button in tab in SystemEntityPolicy.
   

2. When creating Bank account through parent resource belongs_to selector of System Entity is not set automatically:
   avo/resources/bank_accounts/new?via_record_id=2&via_relation=bank_accounts&via_relation_class=Entities::System&via_resource_class=Avo::Resources::SystemEntity
   

Models and resource files

class Avo::Resources::BankAccount < Avo::BaseResource
  def fields
    field :system_entity, as: :belongs_to, only_on: [:new, :show, :index]
  end
end

class Avo::Resources::SystemEntity < Avo::Resources::Entity
  def fields
    super

    tabs do
      field :bank_accounts, as: :has_many
    end
  end
end

class SystemEntityPolicy < EntityPolicy
  def create_bank_accounts?
    BankAccountPolicy.new(user, record).create?
  end

  def edit_bank_accounts?
    BankAccountPolicy.new(user, record).edit?
  end

  def attach_bank_accounts?
    false
  end

  def detach_bank_accounts?
    false
  end
end

Expected behavior & Actual behavior

Expected behavior: bank accounts can be managed through SystemEntityPolicy
Actual behavior: SystemEntityPolicy has no impact on Bank accounts tab

Expected behavior: bank accounts can be created through parent resource with correctly selected System Entity
Actual behavior: the selector is blank

System configuration

Avo version: 3.13.7

Rails version: 7.2.2

Ruby version: 3.3.4

License type:

• Community
• Pro
• Advanced

Are you using Avo monkey patches, overriding views or view components?

• Yes. If so, please post code samples.
• No

Impact

• High impact (It makes my app un-usable.)
• Medium impact (I'm annoyed, but I'll live.)
• Low impact (It's really a tiny thing that I could live with.)

Urgency

• High urgency (I can't continue development without it.)
• Medium urgency (I found a workaround, but I'd love to have it fixed.)
• Low urgency (It can wait. I just wanted you to know about it.)

[adrianthedev]

Hey @sandraa-nestor.
Thanks for opening this issue.
Can you please create a reproduction repo that we can run on our side?

Here's a quick command that will help you generate a new Avo app in no-time.
https://docs.avohq.io/3.0/technical-support.html#reproduction-repository

Thank you!

[Paul-Bob]

I'll address point 1 from the issue. No need to include the policies in the reproduction repository, but please do it with the point 2.

---

By default, each resource has a one-to-one mapping with a policy, with that policy being determined based on the model class tied to the resource.

For example:

• Avo::Resources::SystemEntity uses the SystemEntity model, and thus defaults to SystemEntityPolicy.
• Similarly, Avo::Resources::BankAccount would use the BankAccount model and map to BankAccountPolicy.

When Avo determines which policy class to use, it simply appends Policy to the model class name. This default behavior works the same whether the models involve single-table inheritance (STI) or not.

In your scenario, it seems logical to manage both resources with a single policy file. You can accomplish this by specifying the self.authorization_policy (docs here):

class Avo::Resources::BankAccount < Avo::BaseResource
  self.authorization_policy = SystemEntityPolicy
  def fields
    field :system_entity, as: :belongs_to, only_on: [:new, :show, :index]
  end
end

[sandraa-nestor]

Ahh, I see that... I had an self.model_class option set for SystemEntity resource. That's why I need to set authorization_policy explicitly.

class Avo::Resources::SystemEntity < Avo::Resources::Entity
   self.model_class = ::Entities::System
   self.authorization_policy = SystemEntityPolicy
 ...
end

Now policy works fine, thank you @Paul-Bob!

[sandraa-nestor]

Hey @adrianthedev!
I've managed to reproduce the issue. It's because of foreign_key option on has_many relation

class Users::Student < User
  has_many :marks, foreign_key: :student_id
end

Here is my reproduction repo

Screen.Recording.2024-11-12.at.13.47.31.mov

[Paul-Bob]

Thank you for the reproduction repository @sandraa-nestor

I'll have a look

[Paul-Bob]

Setting the inverse_of on the model association fixes this issue.

class Users::Student < User
  has_many :marks, foreign_key: :student_id, inverse_of: :student
end

Avo occasionally leans on model reflections, particularly when it comes to association fields. Rails usually handles inverse_of automatically, but it seems in this setup, Rails isn't quite catching onto inverse_of unless you configure it explicitly.

My recommendation? Just go ahead and declare inverse_of on all associations to play it safe.

Marking this as done, but feel free to reopen or keep chatting if needed!

[Paul-Bob]

I'm reopening this issue to explore the possibility of identifying this use case and raising a developer-friendly error to prompt the setting of inverse_of.