Allow the specification of resource class names for associative fields

[orenyk]

• What would you like to be able to do? Can you provide some examples?
  • I would like to create a HasMany field for an association whose name is not the same as the associated class name, e.g.

    class Foo < ApplicationRecord
      has_many :foo_bars
      has_many :pubs, through: :foo_bars, source: :bar
    end
    
    class FooBar < ApplicationRecord
      belongs_to :foo
      belongs_to :bar
    end

    If I add a field pubs: Field::HasMany without specifying class_name: Bar in the FooDashboard, Administrate will look for a PubDashboard instead of the BarDashboard. As per Automatic associations #1633 class_name is now deprecated, but all of the field should accept the resource_class option. However, it currently isn't being used to determine the class name for (at least) the HasMany field type.
• How could we go about implementing that?
  • Leverage the non-deprecated resource_class option in the associative fields to determine the resource class if the association has a different name.
• Can you think of other approaches to the problem?
  • Not at the moment

Thanks!

[pablobm]

Thank you for reporting this issue. In theory, the correct class should be detected through reflection at Administrate::Field::Associative, specifically here:

administrate/lib/administrate/field/associative.rb

Lines 14 to 16 in 8408423

	def self.associated_class_name(resource_class, attr)
	reflection(resource_class, attr).class_name
	end

Would you be able to have a look there and see what's going on?

[orenyk]

Yeah let me do a little more digging and follow up. Thanks!

[cyu]

I'm seeing this too, on a has_one with a class_name: option. When we test reflection(resource_class, attr).class_name from the console we do get the expected class name.

I believe the issue has to do something with class load order – since we're declaring those attributes as statics on the dashboard class, they're getting loaded before the AR models are completed initialized. I'll try to make some time to dig into this deeper.

[pablobm]

I think this should be fixed by #2292