Details
-
Type: Improvement
-
Status: Done/Fixed
-
Priority: Minor
-
Resolution: Duplicate
-
Affects Version/s: 2.0, 2.1
-
Fix Version/s: 2.1
-
Component/s: Core CiviCRM
-
Labels:None
Description
When creating a custom field, CiviCRM checks for duplicate names on attempted save and returns the user to the field definition form if the name already exists. This can be problematic, as it's not uncommon to have virtually identical fields in different custom field groups. For example, one might have a confirmation checkbox (serving as an electronic signature) for different events, each of which has it's own set of custom fields. The field and label is identical, but replicated for each custom field group. Current behavior forces you to have a unique name.
I'm guessing this behavior was implemented for two reasons:
1) the field label is used to derive the column name, and you cannot have two identical column names. (In 2.0+ this may appear less problematic, as each custom field group is its own table, and so you could in theory have identical column names in multiple tables. But as I understand the structure, the civicrm_custom_field table still registers all custom fields, and so it would be important to have a unique field/column name in that table)
2) for practical purposes, when selecting a custom field for inclusion in a profile, or when importing/exporting, it would be difficult to have multiple fields with identical names.
Recommended alternative behavior:
1) Do not allow identical field names within the same custom group (return existing error).
2) Allow identical field names in different custom groups. Duplicate check mechanism should append "_1... _2..." etc. to actual column/field name (not the field label) for duplicate(s). i.e. allow identical field labels, but in the backend, create unique field names.
3) In field listings that include custom fields (profiles, import, export, etc.), append the custom group in which each field is defined. e.g. "Custom Field 1 (Custom Group A)". This would clarify where the custom field is derived from, and would probably be helpful regardless of whether duplicates exist.
The issue is basically enabling the ability to have duplicate field labels for custom fields. Since you can control field labels when exposing custom fields through profiles, and there are no duplicate restrictions in the profile interface, this is a low priority issue (i.e. there are existing workarounds). But I think it would be a helpful improvement anyway.