CiviCRM Community Forums (archive)

I've run into an issue (possible bug?) on a client site where Drupal views are displaying CiviCRM data in an inconsistent and unhelpful way.

When pulling data from a CiviCRM custom field, if the field is set up to use radio buttons or checkboxes has never been changed since it was set up, it will show the label, rather than the value, which is generally as it should be. But if it's a select list it has been changed in any way, for example by editing the label or providing a translation into another language, it will show the value instead! Which is a problem.

Example: let's say you have set of options as follows:

• Label: "Federal government", value: "federal"
• Label: "Provincial government", value: "provincial"
• Label: "Municipal government", value: "municipal"

If you set up the field as checkboxes or radio buttons, and then use the field in a view initially, without having modified it, the view will display (if the first option is selected) "Federal government". But if you set it up as a select list modify it in any way, it will forever afterward display "federal" instead.

Why not just use the text you want as the value, you may be wondering? Because if you're creating a multilingual site, that doesn't work - the labels are translatable, but the values aren't. So to use our example above, if you have:

• English label: "Federal government", French label: "Gouvernement fédéral", value: "federal"
• English label: "Provincial & territorial governments", French label: "Gouvernements provinciaux et territoriaux", value: "provincial"
• English label: "Municipal government", French label: "Gouvernements municipaux", value: "municipal"

You can see here that there's a bigger problem - if the site is being viewed in French, you don't want it to just say "provincial" where it should say "Gouvernements provinciaux et territoriaux".

In some cases, an obvious workaround would be to use make the field in question a checkbox or radio button field instead of a select, but that's not always practical - with a list longer than the above example, buttons and checkboxes can get unwieldy pretty quickly. Plus there's no reason that data from select lists should be being handled differently from the others in the first place, as far as I can see.  Edit: I had initially thought this was a matter of select lists as compared to checkboxes and radio buttons, but further experimenting showed that it as actually whether or not the field had ever been edited after its creation. It was just coincidence that on the particular site I encountered this on, a couple of select lists had been edited (to add the French translations), but the radio button and checkbox fields hadn't yet as of when I originally posted this.

I'm fairly sure this is a bug, but as per the instructions at https://civicrm.org/bug-reporting, I'm posting it here first, before filing it with the bug tracker, to see if anyone else has any input to offer.

in a (slightly) related matter - we are looking in to what it will take to provide a formatter within the Views Field so one can opt to show either Key or Value in the way that Views offers this for Drupal select fields
but what confuses me here is that in the civi fields I am testing with, which are radio buttons, I do see the label when I would rather see the value - and the OP seems to be describing the opposite but there is every chance that i am using a civi that has patches backported knowing Eileen.

and i replied there that i am still seeing countries as the 'label' so ... two against one ... i will have a dig and try and figure if we have some special sauce here that has been contributed back (we are pretty good at getting our fixes back in) but that perhaps hasn't been included in the latest release.

What we are seeing is that if the Views field is set up such that is uses the same label as the custom CiviCRM field, then the label gets displayed rather than the value, but if we use no label in Views, we see that the value gets displayed. And if you use a different label, then nothing gets displayed.

We also noted a very curious situation where we had a multi-select country custom field set up, which we called 'Country', and had another single select country custom field, also called 'Country'. The single select field was used in a View, but only displayed the 4 digit code. The multi-select field was not used in the View. However, when looking at the queries generated by the view, the multi-select custom field was being referred to.

We also saw a notice:

Notice: Undefined index: 07 in CRM_Core_BAO_CustomField::getDisplayValueCommon() (line 1318 of /data/www/html/drupal/sites/all/modules/civicrm/CRM/Core/BAO/CustomField.php).

Changing the name of the multi-select country field to something else solved the problem. Sounds like labels are being treated as something more important than just labels.

Thanks petednz
Maybe when you have something ready you could post in this thread with a link and we'll be happy to give it a spin.

Best wishes
Graham