12

My company does not make use of many of the fields provided by civicrm. Our users told me the sheer mass of empty fields is overwhelming them.

I know I could walk the hide-by-jquery-to-death way, but:

Is there a designated or recommended way to disable or hide civi core fields like "nickname" or "legal_name"?

  • Now 2018, going into 2019, still no answer on that feature? – Bruno Vincent Jul 21 '18 at 2:37
  • civicrm is largely built by the community - if the community have not provided a feature you want then perhaps not many folk are fussed enough to put together a solution. Hmm just remembered about the new extension so have added an answer – petednz - fuzion Jul 21 '18 at 4:31
4

The "hide-by-jquery-to-death" way is the way to go for now. (Great name :) )

There are discussions to do that via the web interface in a future version, but that's not there yet.

| improve this answer | |
  • Yap. I'm afraid, you're right. – nielo Feb 9 '16 at 13:14
10

You can hide some of them via the UI at Administer > Customize Data and Screens > Display Preferences

e.g. http://d46.demo.civicrm.org/civicrm/admin/setting/preferences/display?reset=1

Display Preferences

| improve this answer | |
5

The new Extension called Contact Summary Layout Editor is a new tool that may help folk dealing with this type of problem

| improve this answer | |
3

I believe you can create a modified version of the default contact page templates as described here.

Excerpt from that page:

These steps are for any "built-in" screen (e.g. the Contact Summary screen)...

  • Navigate to the screen you want to customize and use your browser to View Source.
  • Search for ".tpl" in the source. You will find a comment line which gives you the path and name of the template used for the screen you are viewing.

<!-- .tpl file invoked: CRM/Contact/Page/View/Summary.tpl. Call via form.tpl if we have a form in the page. -->

  • Locate this file on your server under your ../civicrm/templates path. Make a copy of file in the equivalent path under your new custom templates directory.

  • Edit the file as needed and save.

  • Then clean-up the compiled templates directory, usually by deleting all the directories under your templates_c directory. You can also do the cleanup by enabling CiviCRM debugging and running the directory cleanup command. (NOTE: You do NOT need to delete the standard version of the template from your main CiviCRM codebase. CiviCRM will look for a customized version first, and use that one if found.)
  • You should see your modified version when you reload the CiviCRM screen. If you need help with the templating language, check out the Smarty Documentation
| improve this answer | |
  • Thanks. Maybe I'll do this at some places but because those fields happen to be displayed in various contexts I hope with js/jquery I'll be able to catch some more occurences in a single place. – nielo Feb 9 '16 at 13:14
1

Some example code if you want to remove certain elements on the contact add and edit forms:

/**
 * Implements hook_civicrm_buildForm().
 *
 * Changes some fields on the add and update contact forms
 *
 * @param string $formName
 * @param CRM_Core_Form $form
 */
function MODULE_civicrm_buildForm($formName, &$form) {
  // print_r($formName);
  if ($formName == 'CRM_Contact_Form_Contact') {
    if (($form->getAction() == CRM_Core_Action::ADD) || ($form->getAction() == CRM_Core_Action::UPDATE)) {
      // print_r($form);
      // Add a javascript file for changes in display
      CRM_Core_Resources::singleton()->addScriptUrl('https://EXAMPLE.ORG/sites/all/themes/EXAMPLE/EXAMPLE.js');

      // Remove field override geocoding
      for ($i = 0; $i <= 5; $i++) {
        if ($form->elementExists('address[' . $i . '][manual_geo_code]')) {
          $form->removeElement('address[' . $i . '][manual_geo_code]');
          // $element = &$form->getElement('address[1][manual_geo_code]');
          // crm_Core_error::debug( 'options', $element->_options );
          // also you can add new options w/ $element->addOption( );
        }
      }

      // Remove field signature text
      for ($i = 0; $i <= 5; $i++) {
        if ($form->elementExists('email[' . $i . '][signature_text]')) {
          $form->removeElement('email[' . $i . '][signature_text]');
        }
      }

      // Remove field signature html
      for ($i = 0; $i <= 5; $i++) {
        if ($form->elementExists('email[' . $i . '][signature_html]')) {
          $form->removeElement('email[' . $i . '][signature_html]');
        }
      }

      // Remove field external id
      if ($form->elementExists('external_identifier')) {
        $form->removeElement('external_identifier');
      }

      // Remove field nickname
      if ($form->elementExists('nick_name')) {
        $form->removeElement('nick_name');
      }

      if ($form->getAction() == CRM_Core_Action::ADD) {
        // we can get the contact type from the url ct parameter: Individual/household/organisation
        $contactType = CRM_Utils_Array::value('ct', $_GET, '0');
      }

      elseif ($form->getAction() == CRM_Core_Action::UPDATE) {
        // there is no info in the url so we need to use the contact id and check
        $contactId = CRM_Utils_Array::value('cid', $_GET, '0');
        if ($contactId != 0) {
          $contactType = CRM_Contact_BAO_Contact::getContactType($contactId);
          // $subType = CRM_Contact_BAO_Contact::getContactSubType($contactId);
        }
      }

      // Household
      if ($contactType == 'Household') {
        // Remove custom block
        unset($form->_groupTree[3]);
        // Remove custom block
        unset($form->_groupTree[7]);
        // Change label of household name
        if ($form->elementExists('household_name')) {
          $element = &$form->getElement('household_name');
          $element->setLabel('NEW LABEL');
        }
      }
      elseif ($contactType == 'Organization') {
        // Remove custom block
        unset($form->_groupTree[1]);
        // Remove custom block
        unset($form->_groupTree[7]);
        if ($form->elementExists('sic_code')) {
          $form->removeElement('sic_code');
        }
      }
      else {
        // Individual
      }
    }
  }
}
| improve this answer | |
  • Thanks. Unfortunately I'm afraid that this is too much afford if we take the frontend migration plans of civicrm into account. – nielo Sep 17 at 17:56
  • I'm not sure what you mean with "too much effort". First: this code does a lot more than just remove a simple "nickname" field. Second: the effort of writing code becomes very little once you know how to do it and I think this is a nice example how to do it in a way that targets in a futureproof way the right fields without creating issues with future upgrades of civi. – Hans Rossel Sep 18 at 19:30
  • I'm sorry, I did not want to question your approach in general. It's just I'm not trusting this old form builder stuff to be future proof. – nielo Sep 21 at 7:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.