Check how multifield handles 'required' logic on the multifield itself

Should also define behavior for the following scenarios.

• When a multifield is required and a subfield is optional
• When a multifield is required and a subfield is required
• When a multifield is optional and a subfield is required
• When a multifield is optional and a subfield is optional

Both required, and Both optional are obvious, but what does 'required' mean in the context of a multifield? Does that mean that all subfields should be filled in, or just that *some* data is filled in (only its subordinate required fields)

And if a multifield is optional and has a *required* subfield... what does *that* mean?

Also adding a reference to the emptyness settings issue as it's related.

Well, I would suspect that a required multifield has to enforce the requirement specifications of its subfields, while an optional multifield is valid even if the requirement specification of a subfield is violated. Or in a more strict interpretation one could say that an optional multifield only has a value, if all subfield requirements are satisfied. That would mean that an optional multifield is considered empty until all subtypefield requirements are satisfied. But I guess that's just a theoretical issue, although it's worth considering to get a solid design decision here.
I guess the big question is how you interpret multifield. A multifield can be seen as a preset of fields that can be plugged into an entity at once. Then the entity is aware of the multifield's subfields and any "required"-setting should be propagated to the subfields.
I would advocate to consider multifield to be a tool for building new field types by composition. Therefore an entity may specify whether it required a value or not. What constitutes such a valid composition value is specified inside the multifield. So a required multifield may provide a valid composition value even when an optional subfield is left empty.
As with any other optional field the user may or may not provide a value, but if he decides to do so, the value has to be valid, i.e. has to satisfy whatever is specified for the subfields. It's just the same as with an optional field. Leave it empty or provide a valid value. There's nothing in between.

The addressfield project has the same issue with the definition when this sort of multifield is empty or not and with checking if the subfields are required or not.
There is a patch for that issue described in this comment.
It could be a roadmap for all multifields fields :
- select fields that are required for the multifield to be considered as not empty
- select the operator 'or' or 'and'

Is there a use case where you want to require a multifield but not require a subfield?

I'm not sure it makes sense to have multifield as required at all.

• If a subfield is optional, well so should the multifield.
• If a subfield is required, then that requirement will take care of "all the things" being... required, including the multifield.

See #2442687: Required fields in multifield for delta > 0 aren't required for a patch that re-enabes required fields when delta > 0, this might cast a new light on this discussion.

I agree.

I found myself in this situation (which I think will be the most common): one can fill a multifield (which is optional), but if he fills it, he has to fill some (or all) of its subfields (they are required, to give it a meaning!).

This is impossible to achieve currently.
Even if you set the multifield (on the content type) to be non-required, you will have form validation errors because the required subfields will be empty.

PS: I am using unlimited cardinality on the multifield with some default values on the subfields: the problem is that the first instance is already there, even if you hit "Remove" it will stay there in the table.

The attached patch adds functionality similar to how field_collection handles required fields in (sub) fields. The code is also heavily based on field_collection.

The situation is I have a content type with a multifield that contains a required field and a not-required field.

When the multifield itself is not required the patch does the following:

Case 1: create a new node and don't enter anything into the multifield subfields -> form validates, node is saved, multifield is empty (no row in database)

Case 2: enter something into the not-required field -> form doesn't validate, the required field is highligthed as missing

Case 3: enter something in both subfields -> form validates

Patch fixes also (my) issue #2510102: Empty fields still add a (multi-)value

and also #2442687: Required fields in multifield for delta > 0 aren't required as it didn't make sense to remove the required flags to me.

Cleaned-up #7 a little bit and added boolean field handling the way field_collection does it.

Hi

I have a unlimited multifield that is optional, but all the sub-fields are required. The idea is - you can leave it blank, but if you fill it - fill it completely, so it make sense.

Latest dev works like that - you must fill the first multifield, because its already there with required fields (its ok for me, but it were perfect, if an empty optional multifield with required fields validates nonetheless), but if you add another multifield, its sub-fields are not required anymore.

Is there a patch, that can fix this behavior? I want my subfields of newly added multifields keep required property.

This module does exactly what the field collection module does which is a really big issue:

If a multifield is not required and contains only optional subfields, saving a node without entering any value in the multifield leads to an empty value being saved.

If a multifield is not required and contains at least one required subfield, saving a node without entering any value in the multifield leads to not being able to save the node because it will require a value for that required subfield.

There is a "Remove" button that IMO should really remove the multifield (actually I think that if the multifield is not required, it should not be present at all and one should use the "Add another item" button to add one) and no value at all should be saved for the multifield.

In other words: An optional multifield is not optional at all. It must have at least one value. This is a bug to me.

I agree with #10

If a multifield isn't required then it shouldn't be displayed until the user clicks the add one button. Any fields inside the multifield should deal with their own required state.

@fetzealsvanouds I have gotten around this with a custom field widget form alter that better controls the behavior. I think currently multiform's view on it is that it doesn't support cardinality above 1.

I just hit the same issue as @fetzealsvanouds. I have a multifield which is required itself with unlimited values (meaning that each node should have at least one). It's subfields are a mix of optional and required. The first multifield item added has the correct indicators for required/optional, but any subsequent items added are all optional.

I'd categorize this as a bug rather than a task.

...also, the default values set for the multifield are respected only for the first item. I'll search the queue for any existing issues for that and file a separate issue if not reported already.

[edit] ...reported already (as expected): #2248833: Multifield with unlimited values: Default values are applied only to the first item.

Patch #8 only work in alpha2 version

#8 added to aplpha 4 right after views support and entity API support patches and it works as expected .