Currently the Zend\Form\Element\Collection will discard bound objects and replace them with clones of its dummy template when the form is validated. This will result in loss of all properties that do not have a field in the Collection's target element (fieldset).
Also the returned object instances have to be the same that were passed to the form originally or it will cause corruption.
Fix bug with not preserving the original entity objects in a Collecti…
…on upon validating the form
Add test case for verifying that a Collection preserves original enti…
…ty objects upon form validation
Add fieldset class needed by Zend\Form\FormTest::testPreserveEntities…
Does this have any conflicts with #4077?
Do you mean #4075? Yes, these two PRs do conflict, though my patch would be easy to fix with a single-line check to assert createNewObjects() == false. I don't, though, thoroughly understand why a bug should be restored in the functionality albeit optional.
I noticed there is an attempt to fix this very same bug in commit b0c03a3 but it doesn't test the case extensively. My test case tests for when allow_add == true (in the Collection element) AND initial count is set to less than the actual count of objects contained by the parent object that is bound into the form.
The part of the bug that my PR would fix but the original commit doesn't is to preserve all those entities that increase the amount of Collection's rows from the initially specified value. For example, if count in Collection is initially set to 2 but and object with three sub-objects was bound, the third one would be replaced with a dummy.
[#4077] CS fixes
Merge branch 'hotfix/4077' into develop
Forward port #4077
Merge branch 'hotfix/4077'
Added compatibility with #4077