You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
paper_trail is inconsistent when Version records cannot be created. in some cases (create) an error is raised, in others (update, update_columns, and destroy) an error is logged but not raised. this can result in history silently being lost which is certainly unexpected behavior.
Currently when creating a new versioned record an error is raised if the Version cannot be created - this is because #save! is used:
i think the behavior should be consistent - all failures should either raise errors or not. personally i don't see any advantage to not raising an error in these cases - it likely means that whodunnit isn't defined which i would expect to be an oversight rather than intentional. i realize this is not backwards compatible so i propose a two step process:
an opt-in configuration parameter is added to the current major version which causes update and destroy failures to raise an error.
in the next major version bump this becomes the default behavior.
does this seem reasonable? i'm happy to take this on asap.
The text was updated successfully, but these errors were encountered:
modosc
changed the title
errors are not raised when update or destroy versions fail to create
errors are not raised when update, update_columns, or destroy versions fail to create
Nov 16, 2023
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.
what do i have to do to get human eyes on this? this is a serious actual bug and i created a pr (complete with documentations and tests). is this project dead?
paper_trail
is inconsistent whenVersion
records cannot be created. in some cases (create
) an error is raised, in others (update
,update_columns
, anddestroy
) an error is logged but not raised. this can result in history silently being lost which is certainly unexpected behavior.Currently when creating a new versioned record an error is raised if the
Version
cannot be created - this is because#save!
is used:paper_trail/lib/paper_trail/record_trail.rb
Line 62 in 47dbc22
However, when updating, using
update_columns
, or destroying a versioned record no error is raised if theVersion
cannot be created:paper_trail/lib/paper_trail/record_trail.rb
Line 111 in 47dbc22
paper_trail/lib/paper_trail/record_trail.rb
Line 301 in 47dbc22
paper_trail/lib/paper_trail/record_trail.rb
Line 84 in 47dbc22
proposal
i think the behavior should be consistent - all failures should either raise errors or not. personally i don't see any advantage to not raising an error in these cases - it likely means that
whodunnit
isn't defined which i would expect to be an oversight rather than intentional. i realize this is not backwards compatible so i propose a two step process:update
anddestroy
failures to raise an error.does this seem reasonable? i'm happy to take this on asap.
The text was updated successfully, but these errors were encountered: