New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow whodunnit
to be a proc
#976
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will not be a commonly used feature, but it adds so little complexity that I'm happy to add it.
Please add an entry to the changelog under "Unreleased"
Gemfile
Outdated
@@ -1,2 +1,5 @@ | |||
source "https://rubygems.org" | |||
gemspec | |||
|
|||
gem "rubocop-rspec", "~> 1.15.1" | |||
gem "rails-controller-testing" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not edit the Gemfile
. Please edit Appraisals
instead. But, I don't think any changes to gems are necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kk. I'm not familiar with Appraisals
, but I can go figure it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct, when run via appraisal
, everything is fine.
lib/paper_trail.rb
Outdated
paper_trail_store[:whodunnit].call | ||
else | ||
paper_trail_store[:whodunnit] | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the conditional check respond_to?(:call)
instead of == Proc
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yah, that makes a lot of sense; sharp knives and all that.
expect(described_class.whodunnit).to eq(1) | ||
expect(described_class.whodunnit).to eq(2) | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice test 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:D
Updated as per review and failed tests; rewrote Git history of this branch to keep it super clean. I added a bit to the documentation where I (as a new and inexperienced contributor) was confused. |
Merged. Thanks for your contribution! |
* Allow whodunnit to be a proc * Update contribution quidelines
Basically, I've got a circumstance where I'm trying to figure out what is changing one of my models (it's not Sidekiq jobs, and it's not going through the controllers...).
Right now I've got:
This works, but it also only covers Sidekiq; if there's no place to stick the
whodunnit
initialization like this, there's no way to make thewhodunnit
dynamic and record the actual situation.However, with a change like this, you could set a whodunnit during the creation of the paper trail, so you could evaluate anything you like (inspecting the callstack, the originally run Ruby command, etc etc).
PS - Honestly, I was 100% convinced I wanted this feature as part of tracking down this issue, but in this moment I'm honestly no remembering what the plan was that needed it.... :P
PPS - I totally don't expect this PR to get accepted, but I wanted to start the conversation and figured this'd be more illustrative than making an issue. LMK how I should proceed!
PPPS - I also ran into a couple of issues when first running
rspec
on Papertrail, so there's a couple of Gemfile commits to fix that.