fixes #13574 - remove DB access from Setting class scope
Plugins tend to register an initialiser before config/initializers/ to require their own Setting subclasses. This loads them before config/initializers/foreman.rb, which calls load_defaults on each known Setting class. When loading Setting in a test environment or without a database yet, the class was getting partially loaded once due to a DB call in validates_lengths_from_database 0.4.0 and also in the audited :only call.
When partially loaded, the Setting.load_defaults method wasn't defined, so calling `super` from a subclass failed:
NoMethodError: super: no superclass method `load_defaults' for #<Class:0x00000002d13e48> gems/activerecord-4.1.5/lib/active_record/dynamic_matchers.rb:26:in `method_missing' app/models/setting/general.rb:5:in `load_defaults'
In vlfd 0.5.0, the DB call was removed and it failed on audited instead. Changing the audited options prevents that DB call and so the class now loads just once on both 0.4.0 and 0.5.0. This also removes the need for the hack in plugin initialisers to check if Setting.table_exists? before loading their subclass as class loading is reliable.
Related issues
Bug #13574: Plugins with Setting subclasses raise super: no superclass method `load_defaults' error
fixes #13574 - remove DB access from Setting class scope
Plugins tend to register an initialiser before config/initializers/ to
require their own Setting subclasses. This loads them before
config/initializers/foreman.rb, which calls load_defaults on each known
Setting class. When loading Setting in a test environment or without a
database yet, the class was getting partially loaded once due to a DB
call in validates_lengths_from_database 0.4.0 and also in the audited
:only call.
When partially loaded, the Setting.load_defaults method wasn't defined,
so calling `super` from a subclass failed:
In vlfd 0.5.0, the DB call was removed and it failed on audited instead.
Changing the audited options prevents that DB call and so the class now
loads just once on both 0.4.0 and 0.5.0. This also removes the need
for the hack in plugin initialisers to check if Setting.table_exists?
before loading their subclass as class loading is reliable.