Collections with required fields cannot be configured unless default values are defined.

I second this request. Just because the field is required doesn't mean a default value should be supplied.

csdco, I doubt this is on purpose.

This is probably a validation problem that Field_collection needs to bypass.
But yes, this should be implemented since it prevents you from using the module on some cases, unless you use some workarounds.

For now, you can set the name/surname fields to not-required, then save your form, then set the fields to required again.
That's how I'm doing it.

@BWPanda: Hey Peter, I'm sure you can come up with a less vague issue title that better describes the problem. You won't get any attention if you leave it as it is now. Something like a phrase that includes verbs too perhaps? If what I came up with is not ok with you, simply change it as you see fit ;)

How about this?

...perfect ;)

This one is biting me too. I have required fields, but if I set a default value my users will just accept those defaults without thinking about it. Not good.

(a bit later)

If you don't need to configure anything in the collection instance, you can just exit the collection-edit form without submitting, and your required fields will not have default values set. Coincidentally, this also avoids the issue in #1239946: Embedded field collection items with a default value result in new items on save.

But that's a small subset of cases.

I made a somewhat dirty fix, it works for me. The idea is to enumerate the fields inside the collection on the form build and to remove #required attributes. I do this only for form titled 'Default value'. I didn't find a better way to differentiate between the configuration and ordinal forms.

the original idea of merging tweaked form array didn't work.

patch #9 didn't worked for me

can you elaborate a bit more? What's your use case? Do any errors or warnings or notices appear after patching?

After upgrade to 7.15 I found what patch #9 stopped working. I attach fixed version here.

FYI... Don't believe the patch in #12 applies to the latest dev.

I just (manually) applied patch in #12 to 7.x-1.0-beta4, which seems to just remove the validation-issue.

Saving the configuration of the field in the content type now works. Though, when adding new content the field shows 2 field-collection rows, instead of just 1.

Somehow it saved the empty default values as a new row?

edit: never mind my brainfart. That was me not seeing the 'default value' in a certain field.. /doh

I was not able to reproduce this bug against the latest dev version, 7.x-1.0-beta4+14-dev. Please try upgrading to this version first, and then posting the steps to recreate the bug.

I have the latest dev release and am experiencing this issue also. Steps below.

1. Create a field_collection field on an entity
2. Add fields to the field_collection, mark at least one of them as required
3. Edit the field_collection field settings on the original entity field configuration form
4. Hit save

PS. I haven't confirmed this but it might only be an issue when there is a boolean field set to "single on/off checkbox"

The steps listed in #16 apply to 7.x-1.0-beta5 also. In fact there are two 'Default value' fieldsets on the form. One of them correctly tells you to go to the individual field to set a default value and the other one which shows you a sample of each field and forces you to set a default for required fields.

The work around is to make those fields not required while editing the Field Collection and then marking them required again later but that "= teh suck".

This only seems to happen with a Field Collection Table widget type. Moving this issue.

#19 works for me.