CiviCRM Community Forums (archive)

I needed a custom field, a drop-down list, with many values. Rather than create it manually I wrote a simple PHP script to create it for me. I used crm_create_custom_group to create a custom group, then crm_create_custom_field to create the custom field of data_type => String and html_type => Select within that group. And finally, I used crm_create_option_value to add the custom values to the field. I used strings like "AA-1", "AA-2", etc. for the values and "All Age 1", "All Age 2", etc. for the labels. The creation worked fine. The custom field previewed correctly and went into production. Users were able to modify the field value for their accounts with no trouble.

Then I had needed to change one of the labels. So I went to edit it through the CiviCRM GUI. When I went to save my changes, the GUI prevented the change on the grounds the value (not the label) contained a hyphen (-). The full error message was:

Please correct the following errors in the form fields below:

    * Please enter a valid value for this field. You may use a - z, A - Z, 1 - 9, spaces and underline ( _ ) characters.

So I now have a problem. Many users now have the value containing the hyphen stored in their database record. If I simply update the value in the GUI, it will be out of synch with what's stored in the database. This will be tricky to resolve. I presume I'll have to modify the database directly.

The underlying issue is that API has let me use a hyphen, but the GUI does not. In my view this difference needs to reconciled in the code. What do others think?

Interestingly, most browsers seems to cope with the hyphen just in the HTML. Looking at the HTML 4 standard it seems that a hyphen might be permitted. In which case the GUI code is the one that needs to change.

PS: I'm using CiviCRM 1.9.x.

1. our api's dont do as much checks as the forms. I suspect this happens in a few other cases. Our api support is not very strong (IMO)

Fair enough. Perhaps this could be an area for 2.1 to improve on. From an architecture/design point of view, the API and GUI should use the same validation code. Of course, implementing this is another question

2. Please file an issue and we'll fix in 2.x. Highly likely we will stick to the current form rule and add the check to the api. You can do a str replace in your db. I'm also pretty sure when you change the value, we go in and fix the custom_value table.

OK. I'll file an issue. Should it be a general one to check all API vs GUI validation? Or just stick to this one small case?

Further, when I did update the value, a user who had selected the old value now showed as not having selected anything. This suggests to me that changing the value does not include changing existing uses of the value already in the DB.