The 'required' status for a field in a multigroup does not make sense in the context of the actual group.

The 'required' checkbox on the group itself requires there to be at least one subgroup in the multigroup.

The 'required' checkbox on a field requires that field to be filled out.

The problem is, if the 'required' checkbox in a field is checked, then it also requires there be at least one subgroup, as that field cannot have no values. This prevents the case of a non required multigroup where one or more fields MUST be filled out per item.

Use case:
In my case, I have two fields, "a" and "b". I want "a" to always have a value, but "b" to be optional. Contrast this with the user setting a value for "b" and leaving "a" empty, which would be a valid subgroup if "a" is not marked as required.
However, I also require the multigroup to have 0 rows, as this group is designed to have entries added after the fact (via another module, there's another bug report on that).
Currently, my only choice is to attempt to work around the fact that the user can enter an invalid subgroup by custom php code and the Rules module. This would be a messy workaround and add unneeded complexity.
One could require field "a", and instruct the users to enter bogus values. However, since the purpose of this field is to reference a user for "A" and a node for "B", and the values would be set by another module, this value would be completely meaningless and just muddle up all usages of this field.

Solution: Change the field 'required' behavior to be local only to the subgroup.
I know little about the core of cck at this time, but I figure the required behavior is operated on in there, rather than in the multigroup module, so this would be difficult to pull off without a redesign to push handling of required fields to groups in much the same way multi values can be handled entirely by widgets or formatters.


markus_petrux’s picture

Assigned: Unassigned » markus_petrux

I haven't checked recently, but the idea is:

a) required option at multigroup level means at least one subgroup of elements should be filled in.
b) required option at field level means that particular field must be filled in when the subgroup is used. If the user does not want a subgroup, it can be removed using the remove button.
c) If a subgroup is not removed, but all fields are empty, we may want to ignore the subgroup (should we ignore the required option at field level?).

c) Is not implemented, but requested here: #522564: Ignore empty groups on node submit.

Assigning the issue to myself so I do not miss it.

csc4’s picture

First up - though I'm having problems this is a really great project and your management of your issue queue is incredible. I wish I could help rather than in finding problems...

I'm having a problem with required fields, I have an order line and want a non-zero price and a product description for each order line which is submitted. I'd also like at least one order line, I'm also setting some default values.

If I set the multigroup to unlimited with quantity, price and description required (and price > 0.01) and then use the add more to get new lines this works perfectly.

But, because of the problem where the Add More button isn't working in some browser combinations (in my case it's fine in Firefox, Opera and IE6 and doesn't work for IE 8 which is what my client is using as their browser of choice), I thought I could work round the browser issue by setting the multigroup to 10 but that means they get 10 lines with the require fields set - even if they only fill in two or three line with actual order lines. I can see why this is happening but I can't figure out how to code to avoid!

I'm stuck now trying to decide whether to revert back to unlimited and ask them to use another browser or to remove the required fields checks.

RoboPhred’s picture

csc4, you should check to see if this issue is already posted, and if not, create a new issue for it. Do not interupt an existing unrelated issue.

csc4’s picture

Apologies, I thought my problem was related to group required and fields required and so relevant to this issue.

RoboPhred’s picture

This issue is about how the required fields work. From what I can tell, yours is over the "add more" button not working. You should create a new issue on that.
It's always best to solve the issue at hand rather than work around it (especially if working around it requires a new issue be fixed), so the answer to your issue would be to get the "add more" button fixed for the broken browsers.

A required "x values" field requiring all fields to be filled out is by the design of cck, although the confusion is similar to this issue and might be solved by it in the future.

Go ahead and create the new issue, I didn't find any related to it searching the issue queue. You can link the new issue in here so others who find this issue searching for yours will know where to go.

markus_petrux’s picture

The issue about problems with IE8 was discussed in the middle of this issue: #456976: "Add Another Item" Does Not Work When using Popups API (comments #7 to #11).

In regards to the current issue... I'm just pretty busy focussed on another complex job. I know there are a few things related to multigroup that are pending here, so I'll try to find a hole as soon as I can. Our project also needs the multigroup as stable as possible, so I'll have to fix these issues some time soon. Apologies for not being more concrete, but the time I can spend here does not completely depend on me.

markus_petrux’s picture

Back on to the initial question, I have been spending all day trying to figure out what was missing or incorrect here.

Here's what I've found:

1) We do not have a visual indication when a multigroup is required.
2) When a multigroup is not required and all subgroups are removed, we still get errors related to required fields.

I have already commited a fix for 1) (patch), which was the easiest one.

To fix 2)... well, this one has taken me the main part of the day, trying to figure out where was the problem, and once I found that, trying to find a way to fix it. Well, more about it in a couple of minutes...

markus_petrux’s picture

Status: Active » Fixed

Ok, so here's a bit more about 2) as described in #7...

In CCK3, we have nodeapi('validate') implemented in content module to enforce validation of field requirements for multiple value fields. Multiple value fields that are required, cannot tell FAPI their form elements are required because requirement here means just one value is enough.

On the other hand, the multigroup may or may not be required. If it is required, one subgroup of fields must be filled in. Individual field requirements should apply only when a subgroup of fields is used, contains non-empty fields and it is not flagged for removal. However, when the multigroup is NOT required, we should allow the user to remove all subgroups, and then the validation performed in the previosly mentioned nodeapi('validate') step should not report errors related to required fields part of a non-required multigroup.

The problem is that one part of this validation process happens in FAPI (happens first), the other happens in nodeapi (happens second), and there's no easy way to disable the second validation based on the first one. So, I have used a method that's kind of hackish, but it works. From the validation step at FAPI level I'm setting an array of fields that can be ignored from requirement validation. This array is passed via $form_state['values'] to the $node object that is then processed via nodeapi('validate').

There are always many ways to do things, but sometimes you should say, stop, I cannot spend more time trying to find alternatives. I'm not 100% happy with the solution, but it works, and that is what counts, I think.

Here's the commit:

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

xtfer’s picture

Version: 6.x-3.x-dev » 6.x-3.0-alpha3
Status: Closed (fixed) » Needs work

This doesn't appear to be working under Alpha3. Empty multigroups with required fields will not submit.