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
Comments
Do you have a basic app that reproduces this problem? |
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:
|
Closing due to staleness. |
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. |
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? |
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?
|
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". |
I'm getting this same error in
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. |
@dduqueti I'm also experiencing the same issue with: gem 'rails', '5.1.4'
gem 'audited', '4.4.1'
gem 'paranoia', '2.3.1' |
@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! |
@dduqueti Thanks for the note! I'll give that a try. |
@dduqueti Thanks for your solution!!! |
👍 |
Faced the same issue,
@dduqueti 's workaround did the trick. Thanks! |
@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? |
This is the greatest solution: https://github.com/jhawthorn/discard |
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?
The text was updated successfully, but these errors were encountered: