CATL-2002: Do not reduce the values for hidden elements

[lisandro-compucorp]

Overview

This PR solves the problem experienced by sending a WebForm associated with a Case.
If the case has more than one tag associated, and the tag is a hidden field of the form, then only one of those values is preserved.

Before

In particular, for one of our customers, there is a first form, F1, in which the tags can be selected. The tag field is then rendered with the widget "Select options".
After the Form is correctly saved, a Case is created with, for example, tags Tag1, Tag2, Tag3.
If this same Case requires to get updated through another form, F3, in which the Tags should not be edited (therefore hidden), we observe that after submission Tag2 and Tag3 were removed.

• Result after form F1
  
• Result after form F3
  

After

The tags are all correctly preserved.

Technical Details

In the modified script, this code fragment is verifying if some value to be displayed does not allow multiple options, but is an array:

            if ($element['#type'] != 'checkboxes' && $element['#type'] != 'date'
              && empty($element['#multiple']) && is_array($val)) {
              // If there's more than one value for a non-multi field, pick the most appropriate
              if (!empty($element['#options'])) {
                foreach ($element['#options'] as $k => $v) {
                  if (in_array($k, $val)) {
                    $val = $k;
                    break;
                  }
                }
              }
              else {
                $val = array_pop($val);
              }
            }

I put emphasis on "to be displayed" part, because it is not considering the situation in which those values don't need to be presented.
According to the documentation, and also with the observed during the test of the changes, the "#type" of the a hidden element is 'value': https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.html/7.x#val then we avoid to reduce the options by filtering appropriately.

[jamienovick]

@tunbola @james-compucorp cc @omarabuhussein @ana-compucorp @rebecca-compucorp

This one looks like a PR to our webform fork. Just wanted to raise awareness of this to see how this fits into our overall webform strategy and to confirm this is aligned. It seems to say 5.1 patches which implies to me that perhaps this needs to be a patch to webform core first?

[tunbola]

True @jamienovick. This should go in to webform core 7.x-5.x branch and we can patch it to our fork once approved and merged.