Ability to create a new contact type without being obligated to have Field Name

@bunset - Thanks for the message. The name module seems to really be confusing people, and I will post a video about how to properly administer it sometime this week. The long and the short of it is, you are not obligated to use any parts of the name field for any contact bundle, the field api throws up some misleading messages, and it's possible to configure the name fields for each contact type even after you have already added contacts.

In regards to the specific issue around removing the name field, it's something you have to live with for right now, but it's not actually that hard to work around if you don't want to use it at all.

The name field was chosen specifically as the minimal field requirement for a contact. It's the only field associated with a contact by default, and the only one used in most views for the system. It is also tied into the display of results for several entity reference fields (i.e. activity -> participants), thus making it a little hard to do without.

If you do want to use something else as a primary identifier for contacts, it's not the hardest thing to do.

1) Add some other set of fields you want to use to capture people's names.

2) Hide the display of the name fields.

3) Add the new fields to the main contact view.

4) Adjust the entity reference callbacks to display something besides the name fields.

5) Adjust the contact.tpl.php files to display something other than the name.

6) You would need to do something different with participants fields for the activity and relationship entities. Look at the code there to find some examples of how to theme the names differently.

Bizarre. I just downloaded the latest version of the name module and now I am seeing it to.

Let me look at this over the weekend, this should not be that hard to fix.

I could use some feedback from the community on how to handle the issues with the name field.

The reason the name field is so important is that it allows us to pull information about contacts from a common field. It makes the process of creating views and calling information about a contact much easier, while still keeping some standards in place around how names themselves are collected. At the same time, enough people are complaining about being forced to work with the name field that we might want to make it optional in the first place.

We opened an issue in the name field queue about this here: https://drupal.org/node/2047643. Basically, what we are talking about doing is writing a patch that allows you to override labels and the visibility of fields on a per-bundle basis. We should be able to have a patch ready in the next few days.

What I see as the path forward for this issue is twofold:

1) We write a patch to solve the immediate issue, make it available, and it gets rolled into the name field module.

2) For the D8 version, we retire the dependency on the name field module entirely, and provide some feature that allows people to specify what field refers to names.

What does everybody think about this as a solution?

Update: there is a patch available for the name module that partially corrects this issue. You can download it from this thread #2047643: Support for Per-Bundle Settings on Name Module

What this patch does is set up name fields so field parts and labels can be overridden on a per-bundle basis. This means you can have name parts and labels specific to each entity type.

The next step is a change within CRM Core itself. There is code in crm_core_contact.module, starting at line 973, that was designed to control field labels. It's hard coded for the household and organization contact types, unfortunately, and there's no way to extend it to work with other contact types. It looks like this:

  // For household or organizations, the label should be reflected
  if ($type == 'organization' || $type == 'household') {
    $instances[0]['label'] = $t('@type name', array('@type' => ucwords($type)));
    $instances[0]['settings']['inline_css'] = array(
      'credentials' => 'display:none',
      'family' => 'display:none',
      'generational' => 'display:none',
      'given' => '',
      'middle' => 'display:none',
      'title' => 'display:none',
    );
    $instances[0]['settings']['title_display'] = array(
      'credentials' => 'none',
      'family' => 'none',
      'generational' => 'none',
      'given' => 'none',
      'middle' => 'none',
      'title' => 'none',
    );
  }

This code would override field label settings for organizations and households, but would not handle overrides for custom contact types. While I thought we got all the hacks and clown code out of the modules with the latest releases, but somehow this got by me. It will be removed, and we will be unlocking the name field itself.

Expect a new release of CRM Core this weekend, once the latest updates have been tested. While I realize this is not a full solution to the original issue, what this will allow you to do is modify the name field, customize the parts of names that are collected, and customize the labels for name field components on a per-contact-type basis.

It will also allow you to do is delete the contact_name field altogether and replace it with something more to your liking. This can be a problem, however, and does comes with some important caveats.

1) If you remove the contact_name field, you will need to replace it with another field called contact_name of a different field type.

2) Changing the field type will create issues with various CRM Core UI modules. If you are just looking to use CRM Core as an API, without any UI modules installed, you should not be impacted. If you are looking to use any of the UI modules, you are going to run into some issues.

3) We are still sorting out the impact of changing contact_name to another field type within the UI modules. To be honest, the issues don't look that bad right now, and there is a ticket for tracking the impact of this change over here: #2049427: Deleting contact_name field. Please share any thoughts you have about what may be impacted so we can be on the lookout for it.

4) We are going to decouple CRM Core from the name module for Drupal 7, instead of waiting for Drupal 8. The name field is still important for CRM Core, maybe just not for 100% of use cases. It's time to move in that direction.

So, this patch for the name module was committed: https://drupal.org/node/2047643

I believe it solves the issue. Use with caution.