Boolean value in field collection causes field collection item to be added when user has left it blank

I encountered the same problem, and your hack is working. I hope this will be implemented in near future.

There is some way to avoid this problem by using radio multiple choice with N/A null value preselected, but this is not proper way to handle this problem ...

Attached patch adds a 'The off state should mean an empty field' checkbox to the field instance setting form in case the widget type is 'options_onoff'. If this checkbox is checked then no fc item is created when you leave the field widget unchecked.

Still an issue for me in version 7.x-1.0-beta3+4-dev, patch fails to apply in this version.

Modified patch to also work with the radio buttons widget for boolean fields.

Against 7.x-1.0-beta4 the patch in #4 worked for me. I also used it in conjunction with the patch in http://drupal.org/node/1276258#comment-5969454.

In 7.x-1.0-beta4 not works for me.
It is a very frustrating problem.

Same as jimmynash in #2: works fine when both patches are applied, repeteable behaviour. Thanks for this effort, rocks, the alternative of changing the widget type on the boolean fied was not seductive at all.

#1662998: Create configuration option to ignore chosen collected fields when checking for an empty field collection is an issue to fix this for any field/ field type. I almost want to set this as a duplicate, but the patch here is a good for people looking for a specific fix now.

Keep it DRY though -- I don't think it should be committed, or if it is it should be removed when the ignore fields patch goes through.

This will be stating the obvious to some, but for others like me that were using #4's patch with beta4:

The patch from #4 will not apply to beta5, but don't fret. It is no longer necessary. Instead, see hook_field_collection_is_empty_alter() in field_collection.api.php. Use the example code provided in a custom module to check empty($item->your_field), with your_field being the field(s) you'd like to be filled in order for the collection to not be thought of as empty. If it is empty, set $is_empty = TRUE; and the collection will not be saved.

As mentioned in #15 of #1662998: Create configuration option to ignore chosen collected fields when checking for an empty field collection, this will perhaps eventually have GUI configuration involved, but this is a better fix than #4's patch (no one likes maintaining patches through updates) until then (and perhaps beyond for some).

Thanks for the hook!

I'm using beta 5, not sure how to patch this (applied changes from comments #2 and #4 to no avail)

#4 worked perfectly for me. Thank you!

@Jay Lee :

Can you pls confirm that #4 patch still necessary for 7.x-1.0 beta7 version ? Thanks.

Chintan4u, I'm pretty sure you do. I'm using the latest 7.x-1.x-dev due to it taking care of another important issue, and I still needed to apply it.

Thanks Jay Lee. I will apply this patch to beta7.

4: field_collection_empty_boolean-1339868-4.patch queued for re-testing.

Applying patch #4 to 7.x-1.0 beta7 did not resolve issue.

Applying patch #2 worked

Applying patch #2 to 7.x-1.0-beta7 also worked for me.

I do not think it makes sense to implement workarounds like this for every field type - we should do #1662998: Create configuration option to ignore chosen collected fields when checking for an empty field collection instead which provides a solution for all field types. Leaving this issue open for people running into this though.

However, we could improve our default logic for boolean fields and skip them by default. As they are never empty (and this seems to be correct to me), there is no value in their non-empty status.

Attached is a patch which ignores boolean fields by default unless are field collection fields are booleans. I guess that would be better out-of-the box behaviour than the current one.

Applied the patch from #20 to beta8 and could successfully empty a field collection owning a boolean field.

I had to modify patch #20 as it fail to store a field collection which has only its boolean input(s) checked (the other(s) are empty).

Fix patch #22 (miss to add the $all_boolean computation instructions).

Please, just forget #22 and #24 patches.

hm, I'm not sure what's necessary to handle the all-boolean-field case correctly, but #20 is not too complex and seems to work fine for most situations -> Committed that.

If there are problems left for cases with only boolean fields, please open a separate issue so they can be discussed and addressed.

If you have a field collection with a boolean field and any number of other fields, the boolean value will always be ignored when all of the other field collection fields are empty.

The patch from @drikc in #26 is necessary to cover this scenario, and it worked for me. His patch file seems malformed though—I'll get one posted here in a minute.

Maybe the patch from #26 wasn't malformed, maybe @drikc just made it against a different version or his already-patched file. At any rate, I've attached a patch against the current version.

Updated patch for the latest 7.x-1.x: 1.0-beta11 / #ec024e5.

re-adding patch 32 as 33 to avoid some odd curl issues returning the original -32 that I was going to upload.

+++ b/field_collection.module
@@ -595,8 +595,19 @@ function field_collection_item_is_empty(FieldCollectionItemEntity $item) {
+      foreach ($languages as $langcode) {

You're referencing $languages before $languages is defined. This patch is broken.

Currently if a field collection has boolean and non-boolean fields, and a user fills in only FALSE values for the boolean fields ("No" on radio buttons) the field collection will be treated as if it's empty, which makes no sense as a Radio button value of FALSE is still a value.

Re-rolled the patch to account for this use case, however please inform me if there is a legitimate reason why this use case can not be catered for.

The attached patch now checks if the boolean field value is NULL rather than empty.

Issue during generation of patch, accidentally created patch as interdiff. Updated attached.

The problem with checking for NULL is that it only works for radio button boolean fields because they have an N/A option. Applying this patch would cause check-box boolean fields to always register as non-empty, which I think is the more common use case, and the one that this issue was originally trying to solve.

I agree though just checking for FALSE isn't sufficient either.

@jmuzz

I think there's a bit of a disconnect here. Just because a checkbox hasn't been checked, doesn't make it empty.

If a site has an entityform with a field collection that only contains checkboxes, or primarily checkboxes, on for instance a quiz, and the user filling out said entityform answers FALSE to all the questions in that particular field collection, therefore not checking any of those checkboxes, then that is a valid answer and the field collection is not empty.

No data is still data, as it's the choice of the user to enter no data, and for analytical purposes being able to check that those questions where answered as FALSE is essential. Currently, in the above scenario, there would be not Field collection to query the value of those checkboxes.

The attached patch in #38 resolves this issue.

I get what you're saying, but if you look at the history of this ticket and its title you will find that treating those empty checkboxes as though they are not data was the goal. There is at least one followup issue related to this with the idea of getting it to work in more use cases such as with radio buttons.

It should be possible to add a checkbox to a field collection and still have it register as empty.

Ok, so I'll admit I can never see a case where a 2 state field should ever be untracked, it is either TRUE or FALSE, and if you can't determine which state it is because the entity it is attached to doesn't exist, then it seems broken to me... however I fully accept that others have other opinions.

If this is the case, and there are valid reasons to not be able to determine the value of said 2 state field, then it needs to be made configurable and clear why one would want one or the either behvaiour.

Well say for example you're making hotel nodes and there's an unlimited cardinality field collection to track the vending machines in each hotel which has stuff like what floor the machine is on and a checkbox about whether or not it takes debit. Maybe one of the hotels doesn't have any vending machines. In that case somebody should be able to leave the collection blank and have it not add a vending machine.

I like the idea of a configuration option for it. I understand that was the idea behind one of the followup tickets.