svoop
2012-Jul-02 23:55 UTC
accepts_nested_attributes_for ignores reject_if option for destroy of nested resource
Given the following nested resources: class Blog < ActiveRecord::Base has_many :posts accepts_nested_attributes_for :posts, allow_destroy: true, reject_if: ->(post) { post[:locked] } end class Post < ActiveRecord::Base belongs_to :blog end The reject_if prevents updating any posts for which the locked attribute is true. However, it is still possible to destroy a post no matter whether the locked attribute is true or false. I''m not sure how to tackle this inconsistency - or whether other people consider this behaviour inconsitent as well at all. Here are a few ideas: - Add a "allow_destroy_if" attribute which takes a Proc which returns either true or false (similar to reject_if). - Extend "destroy_if" to accept a Proc which returns either true or false as well. - Always honour "reject_if" before destroying nested resources. (Might be too optionated though.) What do you think? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/A0u51Fv3uMgJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
svoop
2012-Jul-05 13:10 UTC
Re: accepts_nested_attributes_for ignores reject_if option for destroy of nested resource
> > > - Extend "destroy_if" to accept a Proc which returns either true or > false as well > > Oops, that''s wrong, I mean "extend the allow_destroy option" of course.Not too many opinions thus far. :-) It basically boils down to this: Should the reject_if option only be relevant for creates and updates or for deletes as well? I tend towards "yes", but a patch for this will change the behaviour of allow_destroy in conjunction with reject_if. Such an API change might cause headaches on existing applications. (A temporary warning if both options are set might be useful.) Opinions anyone? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/4byqu8qPUOcJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.