I am one of the maintainers of CRM Core. We use the name module for storing information about contacts, and are encountering issues related to storing settings for name fields on a per-entity type basis.

This relates to the following tickets:


The challenge is this:

- we have an entity called Contacts, with multiple bundles (such as Individual, Organization).
- we are looking to use one field (contact_name), common to each bundle, to give us a simple way to retrieve a list of contacts by name.
- for each bundle, there are different requirements around the information we need to collect. For instance, we might need first name / last name for individuals, and organization name for contacts.
- currently, any time we make a change to contact_name, the change is applied globally. Each instance will now have the new settings.

There was a time when it was possible to have settings for each bundle, and it appears something has changed. Is this still possible to do within the Name module?

#13 name-2047643-13-instance-overrides-for-selected-field-settings.patch13.66 KBAlan D.
PASSED: [[SimpleTest]]: [MySQL] 348 pass(es). View
#11 name-2047643-11-instance-overrides-for-selected-field-settings.patch12.17 KBAlan D.
FAILED: [[SimpleTest]]: [MySQL] 348 pass(es), 2 fail(s), and 0 exception(s). View
#9 name-2047643-9-instance-overrides-for-selected-field-settings.patch12.15 KBAlan D.
FAILED: [[SimpleTest]]: [MySQL] 348 pass(es), 2 fail(s), and 0 exception(s). View
#8 name-instance-field-settings-overrides.png34.45 KBAlan D.
#7 per_bundle_settings-2047643-7.patch12.61 KBRoSk0
PASSED: [[SimpleTest]]: [MySQL] 350 pass(es). View
#7 interdiff-2047643-3-7.txt7.86 KBRoSk0
#6 name-instance-field-overides.png25.57 KBAlan D.
#3 per_bundle_settings-2047643-3.patch8.93 KBRoSk0
FAILED: [[SimpleTest]]: [MySQL] 350 pass(es), 0 fail(s), and 35 exception(s). View


Alan D.’s picture

I think that this did once, but that was literally years ago from memory. A quick scan of the first commit post GIT migration only has the field settings (26 Feb 2011).

Happy to consider patches for instance overrides. Note that an additional preprocessor / field alter could be added to name element to alter it's behaviour based on the associated entity IFF this change is globally consistent across the crm. However I expect that this is not the case.

If you consider a patch, I think that this should be fairly limited and just cover the components / min components in the instance settings. I would make this state controlled, nested under a checkbox to toggle the visibility. [ ] Override field settings (or something along these lines)

BTW, CSS settings are being dropped in favor of external CSS / templates in 8.x port, and the autocomplete (names db integration) is being dropped completely in 8.x simplifying things considerably.

pingers’s picture

Hi Alan,
Thanks for the advice!
We're making some progress on a patch, allowing for configuring some settings to be per instance.
Rosk0 will be in touch when it's ready. Cheers!

RoSk0’s picture

Assigned: Unassigned » RoSk0
Status: Active » Needs review
8.93 KB
FAILED: [[SimpleTest]]: [MySQL] 350 pass(es), 0 fail(s), and 35 exception(s). View

Initial patch version.

Status: Needs review » Needs work

The last submitted patch, per_bundle_settings-2047643-3.patch, failed testing.

techsoldaten’s picture

Found a couple bugs with the latest patch, which will be sorted in the next day or so. But it's a good start!

Alan D.’s picture

Nice start. I don't think that I'd include any special logic for the # field instances, KISS reduces the complication internally

I had a quick look at the code last night, simply inserting the label options directly into the other instance settings was fairly tidy, leaving just the component bits as something additional

# name_field_info()
        // Allows a given or family component value to filful either both the
        // minimal components. Allows singular names like "Prince".
        'allow_family_or_given' => 0,
+      'labels' => array('title' => '','given' => '', 'middle' => '', 'family' => '', 'generational' => '',
 'credentials' => ''),

# _name_field_instance_settings_form()
    $form['inline_css'][$key] = array(
      '#type' => 'textfield',
      '#title' => t('Additional inline styles for !title input element.', array('!title' => $title)),
      '#default_value' => isset($settings['inline_css']) ? $settings['inline_css'][$key] : '',
      '#size' => 8,
+    $form['labels'][$key] = array(
+      '#type' => 'textfield',
+      '#title' => t('Label for !title', array('!title' => $title)),
+      '#default_value' => $settings['labels'][$key],
+      '#size' => 12,
+    );

# _name_field_instance_settings_pre_render($form)
        . '
  • ' . t('Additional inline styles for the input element. For example, "width: 45px; background-color: #f3f3f3"') . '
  • ' + . '
  • ' . t('Optional overrides for field labels.') . '
  • ' .... unset($form['instance_inline_css'][$key]['#description']); unset($form['instance_inline_css'][$key]['#title']); + unset($form['instance_labels'][$key]['#description']); + unset($form['instance_labels'][$key]['#title']); ... $form['styled_settings']['tbody']['inline_css'][$key]['#weight'] = $i; + $form['styled_settings']['tbody']['labels'][$key] = $form['instance_labels'][$key]; + $form['styled_settings']['tbody']['labels'][$key]['#prefix'] = ''; + $form['styled_settings']['tbody']['labels'][$key]['#suffix'] = ''; + $form['styled_settings']['tbody']['labels'][$key]['#weight'] = $i;


    RoSk0’s picture

    Status: Needs work » Needs review
    7.86 KB
    12.61 KB
    PASSED: [[SimpleTest]]: [MySQL] 350 pass(es). View

    @Alan D.: Thanks for guidance. New patch version includes proposed way of override components labels and some other fixes.

    Alan D.’s picture

    Number of issues found while looking at this, I will address in the next week or so.

    The biggest was the UI, the instance settings should not be in the field settings IMHO. I am starting to refactor and this is the UI that I am considering. Overrides are in the main table and are always visible.

    Then there are a few other things that need addressing, but I should have time soonish to finish off. ETA by the end of next weekend.

    Alan D.’s picture

    Assigned: RoSk0 » Unassigned
    12.15 KB
    FAILED: [[SimpleTest]]: [MySQL] 348 pass(es), 2 fail(s), and 0 exception(s). View

    And the promised patch ;)

    As far as I can tell, only devel_generate and some validation issues were missing from #7, and added here, but I must say that this patch has had very little testing.

    Status: Needs review » Needs work
    Alan D.’s picture

    Status: Needs work » Needs review
    12.17 KB
    FAILED: [[SimpleTest]]: [MySQL] 348 pass(es), 2 fail(s), and 0 exception(s). View

    Me bad, this one was tested on both an instance and a default (field) name field... Test failure still to check...

    Status: Needs review » Needs work
    Alan D.’s picture

    13.66 KB
    PASSED: [[SimpleTest]]: [MySQL] 348 pass(es). View

    Empty test on the field components was throwing that message. If empty, the minimum component required message is suppressed as the fields are required and that message is shown. (i.e. change required to bypass validation of the instance settings which can be empty)

    Alan D.’s picture

    Status: Needs work » Needs review
    RoSk0’s picture

    Status: Needs review » Reviewed & tested by the community

    Patch works great.

    Homotechsual’s picture

    Patch works great.

    Alan D.’s picture

    Status: Reviewed & tested by the community » Fixed

    Wow, two reviews... two more than 98% of all patches in my queues ;)

    Thanks guys, committed.

    Will watch the usage rates and consider pushing a new tag in the next month or so.

    techsoldaten’s picture

    Right on! Happy to see this committed.

    Status: Fixed » Closed (fixed)

    Automatically closed -- issue fixed for 2 weeks with no activity.

    webflo’s picture

    Version: 7.x-1.x-dev » 8.x-1.x-dev
    Issue summary: View changes
    Status: Closed (fixed) » Patch (to be ported)