Skip to content
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

Does not work with audited-activerecord #34

Closed
daveroberts opened this issue Nov 5, 2012 · 16 comments
Closed

Does not work with audited-activerecord #34

daveroberts opened this issue Nov 5, 2012 · 16 comments

Comments

@daveroberts
Copy link

I created a basic rails app with paranoia and audited-activerecord. I made a model both audited and acts as paranoid. When I try to delete a record, I receive an error that you cannot call create unless the parent is saved (presumably because the audit record is trying to reference the deleted entry).

Has anyone worked around this problem?

@radar
Copy link
Collaborator

radar commented Nov 15, 2012

Do you have a basic app that reproduces this problem?

@daveroberts
Copy link
Author

Yes: https://github.com/daveroberts/audited-paranoia-test

It looks like you can work around the problem by adding :except => [:deleted_at] to the audited definition. I have that commented out.

To reproduce:

  1. Clone the repo
  2. start the server: bundle exec rails s
  3. Navigate to http://localhost:3000/posts
  4. Try to delete a post.

@radar
Copy link
Collaborator

radar commented Oct 11, 2014

Closing due to staleness.

@radar radar closed this as completed Oct 11, 2014
@radar
Copy link
Collaborator

radar commented Oct 11, 2014

I don't have time to investigate this issue and I'm not invested in finding a fix for this at all. Also, nobody else has complained about this issue happening.

@daveroberts
Copy link
Author

What do you mean by staleness? Were you waiting for me to do something else? I provided a minimal code example of the problem the day after you requested it. How many people need to report a bug before it's fixable?

@radar
Copy link
Collaborator

radar commented Oct 11, 2014

As I said, I am not invested in fixing this problem. You have reported it only. Nobody else has. What is my incentive to investigate and fix this issue?

On 11 Oct 2014, at 20:20, Dave Roberts notifications@github.com wrote:

What do you mean by staleness? Were you waiting for me to do something else? I provided a minimal code example of the problem. How many people need to report a bug before it's fixable?


Reply to this email directly or view it on GitHub.

@daveroberts
Copy link
Author

The incentive would be to fix bugs in your software. You can close the issue without addressing it if you'd like, but I would recommend keeping active bugs as open issues. By closing the issue you are hiding a bug in your library.

It may not be common to use the paranoia and audited gems together, which may be why other people haven't reported this issue. For the few people that may want to use these gems together in the future, they won't see that there is an open and outstanding issue, or a workaround to this issue they will encountered.

I'm not demanding a fix to this issue. We didn't wait for a fix two years ago, nor could we have afforded to wait. Since we encountered this bug in production, we've used the workaround that I suggested above. I reported the issue to make the library owners aware of issues with their software. If I were in your position, even if I had no drive to fix the issue, I would still keep the issue open, to let others know that there is a bug when you use this library with another library, and there is a workaround to the buggy behavior in lieu of a fix.

I understand why having a low open issue count is appealing to developers. But I would rather have a project with "one open issue and one known bug" rather than a project with "zero open issues, and one unknown bug".

@dduqueti
Copy link

dduqueti commented Apr 28, 2017

I'm getting this same error in Rails 5.0.0.1 with:

gem 'audited', '~> 4.3'
gem "paranoia", '~> 2.2'

The workaround didn't fix it, so I guess I'm blocked. Thank you for your efforts @daveroberts with this issue and thanks to contributors for the gem.

@mrsweaters
Copy link

@dduqueti I'm also experiencing the same issue with:

gem 'rails', '5.1.4'
gem 'audited', '4.4.1'
gem 'paranoia', '2.3.1'

@dduqueti
Copy link

@mrsweaters As a work-around I had to prevent audits for destroy action, like this:

audited on: [:create, :update]

It's not the wanted functionality but it was the only way I was capable to at least track audits for updates. Hope it helps!

@mrsweaters
Copy link

@dduqueti Thanks for the note! I'll give that a try.

@faqndo97
Copy link

faqndo97 commented Jun 5, 2018

@dduqueti Thanks for your solution!!!

@pabluc
Copy link

pabluc commented Jun 5, 2018

👍

@anujmiddha
Copy link

Faced the same issue,

gem 'rails', '5.0.6'
gem 'paranoia', '2.2'
gem 'audited', '4.7'

@dduqueti 's workaround did the trick. Thanks!

@matiasgarcia
Copy link

@radar Any insights on how to fix this? We are using audited + paranoia and this is a kind of blocker. If you are not willing to invest in fixing this can you provide some guidance on where the error could be so we can try to submit a PR that remediates this issue?

@staleo
Copy link

staleo commented Jul 20, 2021

This is the greatest solution: https://github.com/jhawthorn/discard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants