Hi @carltongibson,

Let's try and agree the expected behaviour.

The ticket explained that it is odd to allow a null response when a widget is required. This is true; however, just looking at the clean validation for a moment, I think the existing behaviours meet this requirement. What is needed is row 6 in the table below, I had tried to fix this by changing the behaviour of test 2. I now believe this to be the incorrect approach. The table below I've reverted the clean logic back to the existing behaviour.

To bring this to life I think there are two valid use cases.

1. You have a field with a number of subwidgets, say a telephone field, it could be acceptable to not enter a number at all; but if you are going to fill it in, then fill it in correctly [row 2 in table].

2. Taking the telephone example above, maybe we want them to fill it in, but it's OK not to fill in an extension [row 6]

Whilst this satisfies the requirement from a clean perspective. The issue is that under scenario 2, this currently results in a HTML5 required attribute being added to all of the fields, irrespective of the widget's required status. My current view is therefore that the change we need to make is to the HTML5 required attributes under scenario 5 in the table below.

a b c d e f [ref]
F | F | F | F | n/a | Valid - Test 4
F | F | T | T | Valid | Incomplete Error- Test 4
F | T | F | F | Valid | Valid - Test 2
F | T | T | F | Valid | Valid - Test 2
T | F | F | F | n/a | Valid- Test 3
T | F | T | T | Required Error | Incomplete Error - Test 3
T | T | F | T | Required Error | Required Error - Test 1
T | T | T | T | Required Error | Required Error - Test 1

a = required
b = require_all_fields
c = subfield.required
d = HTML5 required
e = Entire field not completed test
f = Partially completed test

Appreciate your thoughts.

Some further thoughts on this. Apologies, for another long post....

Whilst we still need to agree the correct behaviour (previous post) I need to find a way of managing required at a more granular level. I've found, what I think, is a neat way of fixing this but causes many of the tests to fail.... (more on this later)

The issues I've been struggling with is that boundfield only adds attrs at the parent widget level. We need a more granular level of control. Therefore here is a 'gist' which shows my current idea.

Step 1) Set the sub widget's is_required on __init__ of the field, in a similar way to other fields.
Step 2) Let's use that variable when building the context for each subwidget in MultiWidget.get_context().
Step 3) Add an exception to boundfield.build_widget_attrs(), to not add required to MultiWidgets

This works and I think is much cleaner than my previous options. (I don't think it permanently changes with widgets attrs for example.)

There is a big but... many of the tests currently fail. This is because the zip in the MultiValueField __init__ method assumes self.widget is a MultiWidget with subwidgets. If this isn't the case then it fails. Some of the tests in the test suite are only testing the field and so haven't setup a MultiWidget.

So my question: Is there a use case for a MultiValueField where it's widget doesn't have subwidgets where the number of subwidgets and fields are equal?

I think the answer to this should be no......

Hi @dcsmith1. I had a look here and left some remarks on the original ticket. Essentially, I think we can vastly reduce the scope of the changes here by not making changes to validation and only dealing with the required HTML attributes in a scenario where required=True and require_all_fields=False on a MultiValueField.