[Rails 7.2] Association named 'audits' was not found on Model; perhaps you misspelled it?

[w-zygmuntowicz]

System configuration

ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux]
Rails 7.2.1
motor-admin 0.4.28

Description

When trying to create a new record an error appears:

Stack trace

I include the stacktrace in a file motor-admin.log

Steps to reproduce

1. rails new testing_motor
2. cd testing_motor
3. bin/setup
4. Append "gem 'motor-admin'" to the Gemfile
5. bundle install
6. Apply the quick fix from there Installation generator fails with error  #173 (comment)
7. rails motor:install && rake db:migrate
8. rails g model Post title:string body:text
9. rails db:migrate
10. rails s
11. Visit http://localhost:3000/motor_admin/data/posts
12. Try to create a new post

[w-zygmuntowicz]

There's a possibility the issue is connected with that one collectiveidea/audited#725 however not sure yet

[pond]

Very likely. More directly, the problem is rails/rails#52715.

Rails 7.2 interferes with the ability to inherit non-STI from a base class, unless that base class has a table defined. The author of the patch that introduced this bug (see above) decided it was not-a-bug quoting AR's STI docs about setting abstract, which seemed fair enough at face value - except the Audited gem and, presumably, herein, it's not an STI use case - on which:

• https://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html, at the very start - "If you don’t have a type column defined in your table, single-table inheritance won’t be triggered. In that case, it’ll work just like normal subclasses with no special magic for differentiating between them or reloading the right type with find." (my emphasis)

Now, ApplicationRecord is a good example of something that we inherit from but has nothing at all to do with STI, and that sets abstract. There is documentation confusion arising about the exact reason for this flag which should be addressed.

Now, this is messy, it's first thing in the morning local time before I've had coffee, but I think this is the situation...

• In Rails 7.1 not setting the abstract_class flag in a base class would cause ActiveRecord to infer the table name. Any subclasses would use that inferred base class table name, unless overriding with self.table_name = .... No existing table name from that base class would be required unless actually instantiated.
• In Rails 7.2 this behaviour is changed, with apparently the base class inferred name always needing to exist. The only way to stop it doing that is to set abstract_class, but now STI-like behaviour kicks in, and ActiveRecord will auto-infer table names for each subclass and never infer it from the base class!
• There is no way to recover the old flexibility; it's simply gone; you have to know exactly how your code base is being used to determine whether or not you can safely set abstract_class and whether or not subclasses might need to set a table name manually. For gems, knowing all possible downstream uses of the gem may be impossible, which is why all I could do in Rails 7.2 compatibility: Add README.md note about custom audit table names collectiveidea/audited#726 was suggest a README.md addition.

The Rails maintainers examining the issue have refused to fix it. I disagree with that choice. Given their behaviour on the issue and the way they weighed in on the Audited issue too, I have no intention of pursing it further, but if others feel that it's a bug, I encourage you to submit a bug report to the Rails team following their required template.

In the mean time, gem author, if your Motor::Audit class is the only place where you use a subclass with a custom table name, I recommend the Rails 7.2 work-around hack (it's a hack insofar as the flag is documented for STI use, but we're not using STI) of adding self.superclass.abstract_class = true under line 5 where the table name is set:

https://github.com/motor-admin/motor-admin-rails/blob/master/app/models/motor/audit.rb#L5

For example, we have:

class AuditTrail < ::Audited::Audit

  self.table_name = 'audit_trails'
  self.superclass.abstract_class = true

   ...
end

[w-zygmuntowicz]

@pond Thank you very much for your guidance

I have a good and a bad news. The good one is I managed to fix the issue locally and I'm going to send a PR this week.
The bad one is I've found another issue, but only when updating the records