Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Nested Attributes: _destroy should work independent of reject_if

#6006

Given the following model examples:

    class Man < ActiveRecord::Base
      has_many :interests
      accepts_nested_attributes_for :interests,
        :allow_destroy => true,
        :reject_if => lambda { |attrs| attrs[:topic].blank? }
    end

    class Interests < ActiveRecord::Base
      belongs_to :man
    end

When supplying a _destroy truthiness in the attributes hash, the record should be destroyed regardless of the return value of the reject_if. This was previously the case in Rails 3.0.0, has regressed as of 3.0.3. In our above case, the following attributes should still mark the associated record for destruction (given an Interest id of 42):

    {:interests_attributes => { :_destroy => "1", :id => 42 } }

We have attached a patch with test to fix this functionality.

Reported by Durran Jordan · November 18th, 2010 @ 05:28 PM

State: committed
Milestone: 3.x
Assigned to: José Valim José Valim
Importance: Low

Activity

  1. Adam Lowe
  2. Johmas
  3. Shay Arnett
  4. Desi
  5. Tim Pope
    Tim Pope
    • Tag changed from marked_for_destruction, nested_attributes_for, reject_if to marked_for_destruction, nested_attributes_for, reject_if, verified

    This looks to be an unintended consequence of https://github.com/rails/rails/commit/097240f60215b866d24aebd02cc41... which was in response to #5579 Rails3 - accepts_nested_attributes_for reject_if option does not work.. The fix gets a +1 from me: It's just a single, self-explanatory line plus a test.

    November 19th, 2010 @ 12:58 AM

  6. Neeraj Singh
    Neeraj Singh
    • State changed from new to open
    • Milestone set to 3.x
    • Assigned user set to José Valim
    • Importance changed from to Low

    oops!!

    did not see the impact with _destroy option.

    +1

    November 19th, 2010 @ 09:53 AM

  7. Sakchai Siripanyawuth
  8. Tim Brandes
  9. Dennis Rogenius
  10. Santiago Pastorino
    Santiago Pastorino

    Hey Durran I'm going to push your fix but can you rebase the patch. Doesn't apply cleanly anymore :(.
    Thanks.

    April 4th, 2011 @ 11:59 PM

  11. Durran Jordan
    Durran Jordan

    I've attached the new patch which is rebased against current master.

    April 5th, 2011 @ 10:04 AM

  12. Repository
    Repository
    • State changed from open to committed

    (from [a9b4b5da7c216e4464eeb9dbd0a39ea258d64325]) Destroying records via nested attributes works independent of reject_if:

    • When a :_destroy truthiness is provided in the attributes hash, the record should get destroyed regardless of the result of the proc or method supplied to :reject_if. (If :allow_destroy is true)

    [#6006 Nested Attributes: _destroy should work independent of reject_if state:committed]

    Signed-off-by: Santiago Pastorino santiago@wyeworks.com
    https://github.com/rails/rails/commit/a9b4b5da7c216e4464eeb9dbd0a39...

    April 5th, 2011 @ 02:39 PM

  13. Santiago Pastorino
    Santiago Pastorino
    • State changed from committed to open

    Hey Durran I've pushed it to master, now can you rebase it to apply on 3-0-stable?

    April 5th, 2011 @ 02:41 PM

  14. Durran Jordan
    Durran Jordan

    Here's the patch against the 3-0-stable branch.

    April 5th, 2011 @ 03:02 PM

  15. Repository
    Repository
    • State changed from open to committed

    (from [30264bb57b0f54c5bdd7cd23d0a29b36879954a3]) Destroying records via nested attributes works independent of reject_if:

    • When a :_destroy truthiness is provided in the attributes hash, the record should get destroyed regardless of the result of the proc or method supplied to :reject_if. (If :allow_destroy is true)

    [#6006 Nested Attributes: _destroy should work independent of reject_if state:committed]

    Signed-off-by: Santiago Pastorino santiago@wyeworks.com
    https://github.com/rails/rails/commit/30264bb57b0f54c5bdd7cd23d0a29...

    April 5th, 2011 @ 04:29 PM