Open domingo2000 opened 6 months ago
We are running into a similar situation where we have a weird setup with a shared module that defines logic between two ActiveRecord classes that write to the same database table and are treated as the same entity.
We want to be able to track the history as a single entity, doesn't matter which of the two classes triggered the change. This looks like:
class Shared
extend ActiveSupport::Concern
included do
self.table_name "shared_model"
has_paper_trail(
meta: {
item_type: "SharedModel"
}
)
end
end
class Foo
include Shared
end
class Bar
include Shared
end
After the upgrade to PaperTrail 14 this is now also throwing an error. And if we would remove the item_type
setting it would result in the versions table having entries for Foo
and Bar
instead of SharedModel
.
If possible we would also like to have an option to configure this somewhere.
This issue has been automatically marked as stale due to inactivity. The resources of our volunteers are limited. Bug reports must provide a script that reproduces the bug, using our template. Feature suggestions must include a promise to build the feature yourself. Thank you for all your contributions.
@jaredbeck is it possible to open again the has_paper_trail meta: { item_type: 'Foo' }
for this use cases?. We still need this in the new Paper Trail versions.
Check the following boxes:
paper_trail
gemThis issue is about using paper_trail with rails and good migrations, so the template does not apply for this case, but i will put as much information as possible to reproduce the issue.
The bug is the following. When running a migration with good migrations the application does not autoload all the models. So a mock class needs to be created if it's necessary to use the model in the migration.
The problem is that when given a mock class in the migration, PaperTrail instead of taking class
Foo
it takes the classBackfillFooNames::Foo
and theitem_type
takes the valueitem_type: BackfillFooNames::Foo
instead ofitem_type: Foo
. This is problematic because then the versions created by papertrail during the migrations are inconsistent with the ones in the application and cannot be used.Here is the information and code to reproduce:
Migration code:
Our solution in papertrail <
14.0.0
is to also mock theitem_type
using themeta
option as shown in the following code:The problem is that in PaperTrail 14 introduced a breaking change that makes that meta attribute forbidden, so now the code above can not run in versions
>= 14.0.0
Here is more data to reproduce the problem
Papertrail version:
15.1.0
Rails version:6.1.7.7
Gemfile:
Gemfile.lock dependencies:
As i see maybe you could rollback the forbid of
has_paper_trail meta: { item_type: 'Foo' }
at the own user risk and document that is risky to change that parameter as was before. Or maybe you have a better solution passing anothe parameter to thehas_papertrail
that could be used in the mock classes.Im willing to open a PR to fix this issue.