Visibility rules aren't saved for unlimited multiple value fields

Hmm, very strange. I tested this case, everything was OK. I can see and fix this problem.

Something strange happens with the form state:

  $form_state = array(
    'plugin' => $plugin,
    'id' => $id,
    'test' => &$access['plugins'][$id],
    'access' => &$access,
    'contexts' => $contexts,
    'title' => t('Edit criteria'),
    'ajax' => TRUE,
    'ajax' => TRUE,
    'modal' => TRUE,
    'modal return' => TRUE,
  );
...
  $form_state['test']['settings'] = $form_state['values']['settings'];
  $form_state['access']['logic'] = $form_state['values']['logic'];

After that, $form_state['access'] != $access.
So I suggest to extract $access from $form_state['access'] before using it. The patch adds such extraction.
The same problem exists in Panels module which requires a separate patch.

The issue and the patch for Panels: #2504465: Visibility rules aren't saved for unlimited multiple value fields.

patch #4 works for me

This seems pretty safe.

This didn't get added to 7.x-1.10.

I am trying to test this but unable to reproduce it. I added a list field of unlimited cardinality to my article node type. Then I went into the node_view and added a selection rule based on the value of it. It showed up as expected. I looked at the function the patch is addressing and it doesn't look to be using $form_state. I'm wondering if this code has changed since the patch was made? If someone could provide exact steps to reproduce, I'd be happy to try again.

Can someone please confirm this is still a bug, and if so provide details of how to reproduce it.

I am able to reproduce this with the following.

Ctools version = "7.x-1.12"

• Create node type 'foo' with multiple fields, one of which being a text field ('bar') which allows for unlimited entries.
• Create 'foo' node, populating all fields, and multiple values for field 'bar'.
• Enable panel page node variant, and select this node type for the selection rule.
• Add relevant fields to variant content region(s) (doesn't matter where, you could also just add a custom block with ipsum text within)
• Add visibility rule to one of the elements, select field: 'bar', which should bring up the edit form. Enter desired value in the table field provided, save. (Note: I also get an error when selecting 'Add another item', Fatal error: Call to undefined function panels_edit_configure_access_test_form_validate() in /opt/sites/jnl-ghostrider/drupal-webroot/includes/form.inc on line 1520)

Now edit this visibility rule and find the value empty. Also, the summary text will be displayed as 'bar is set to ""'

Hope this helps.

Since this issue has garnered more attention than the similar panels version #2504465: Visibility rules aren't saved for unlimited multiple value fields, I will leave the status as-is, however I would like to make a notion that we move for the inclusion of the patch from #4, if anything to fix the issue with panels where a 'null' or empty value field isn't saving the "NOT" declaration.

By applying both this patch and the patch mentioned above for panels, I am able to save it to NOT show the null / empty value.

This patch does fix at least one problem associated with it. I suggest that instead of leaving this problem open for longer than it needs to be in order to "fix everything", we get this patch committed and address the multivalue issue in a new thread if the problem still exists.

Unless someone has an objection, let's move this to RTBC so it can gain some attention for being committed so more focus can be placed on issue #1188466: Add a simple selection rule for checking if a field is empty which will allow the visibility to actually work against an empty / null value. Patch #42 from that thread appears to be working just fine.

Marking this as RTBC because the supplied patch fixes most, if not all of the problems described. Since there have been no other patches to enhance the original, and I have personally used this on multiple sites (as recently as July 2017) with the intended outcome the patch fixes (along with the others mentioned), I believe it's "finally" time to get this committed.

Tagging the next stable release for being committed.

I agree we can continue this in another issue. This small patch does somewhat fix the issue at hand. Panels isn't committed yet, but will be forthcoming. Fixed.

Sweet!!! Million Thx @japerry!