CiviCRM Community Forums (archive)

Hmm, that sounds odd. Can you upgrade to 4.2.4 and see if that helps?

I've tried this in 4.2.4 and the problem is still there. Increasingly I think this is not a version-specific problem.

Thanks, Deepak.

I've narrowed things down futher. The problem is somehow related to the sub-types which I have created using the API. When custom field sets are associated with a manually-created sub-type then the edit screen correctly records the data. When the custom field sets are associated with a sub-type created using the API then the edit screen does not save the custom field data.

It doesn't seem to matter whether the custom group is created by hand or by API. But it matters about the underlying contact sub-type.

However, I cannot see any difference in the civicrm_contact_type table between those sub-types created by hand, and those created by the API. Is there another database table in which attributes of the contact sub-types is being stored, in which there may be a difference?

Thanks, Deepak. Really appreciate your help. I'm still baffled.

- what exact apis you used and how you created it.

# We call a wrapper function like this...
create_civi_contact_subtype(array("name" => "LCBRU Staff", "parent_id" => "1", "description" => "Staff working for the LCBRU.")); // Create sub-type: LCBRU staff

#utility function to create civi contact subtype
function create_civi_contact_subtype($params) {
  civicrm_initialize();
  $params['version']='3';
  $cs = civicrm_api('ContactType','get',$params);
  if ($cs['is_error']) {
    throw new Exception("Error looking for contact type:".$cs['error_message']);
}
  if ($cs['count']==0) {
    $cs = civicrm_api('ContactType','create',$params);
    if ($cs['is_error']) {
      throw new Exception("Error creating contact type:".$cs['error_message']);
}
  } else {
      throw new Exception("Contact type already exists.");
  }
  return array_shift($cs['values']);
}



- how did you create same thing from UI.

http://localhost/drupal-7.15/civicrm/admin/options/subtype?reset=1

Then click 'Add Contact Type'. Complete the 'Name' field and optionally the 'Description' field. That's it.


- and on what url you observing the weird problem.

The standard add or edit forms for contacts and cases, such as:

http://localhost/drupal-7.15/civicrm/contact/add?reset=1&context=search&action=update&cid=20

In such a situation, submitting data against custom fields in groups which extend API-created types will result in data not being saved, whereas data submitted to custom fields in groups which extend default types ('Individual') or manually (UI) created types will be correctly saved. If groups of both types are relevant to a created or edited contact, data will be saved only against fields within the groups which extend default or UI-created types.

- are you able to reproduce the problem by repeating above steps on latest install ? If not, what civicrm version you upgraded from and created most of the custom fields from apis.

Yes, I've done a clean install of 4.2.4 and the same behaviour is exhibited.

* * *

It seems to me that there must be a problem with how I have created the contact types in the API. However, here is my civicrm_contact_type table:
mysql> select * from civicrm_contact_type;
+----+---------------+---------------+---------------------------------------------------------+-----------+-----------+-----------+-------------+
| id | name          | label         | description                                             | image_URL | parent_id | is_active | is_reserved |
+----+---------------+---------------+---------------------------------------------------------+-----------+-----------+-----------+-------------+
|  1 | Individual    | Individual    | NULL                                                    | NULL      |      NULL |         1 |           1 |
|  2 | Household     | Household     | NULL                                                    | NULL      |      NULL |         1 |           1 |
|  3 | Organization  | Organisation  | NULL                                                    | NULL      |      NULL |         1 |           1 |
|  4 | Contact       | Contact       | Individuals who we might recruit into research studies. | NULL      |         1 |         1 |        NULL |
|  5 | LCBRU_Staff   | LCBRU Staff   | Staff working for the LCBRU.                            | NULL      |         1 |         1 |        NULL |
|  6 | Health_Worker | Health Worker | All health workers, whether LCBRU staff or otherwise.   | NULL      |         1 |         1 |        NULL |
|  7 | GP_Surgery    | GP Surgery    | NULL                                                    | NULL      |         3 |         1 |        NULL |
|  8 | Contact_2     | Contact 2     | testing type                                            | NULL      |         1 |         1 |        NULL |
+----+---------------+---------------+---------------------------------------------------------+-----------+-----------+-----------+-------------+

ID 4 ("Contact") is API created, data does not save against the fields in custom groups extending this contact type. ID 8 ("Contact 2") is created through the UI, and data saves correctly against fields in custom groups extending this contact type.

I can switch the settings for a single custom group to extend either of the contact types, back and forth between the two, and the behaviour continues. Extending id 4, data is not saved. Extending id 8, data is saved. Back to extending id 4, once again the data is not saved. Yet the two contact types have idential settings in this table.

Data which is submitted against the same custom fields using API calls is correctly saved, as is data submitted using the AJAX 'add or edit' mini-forms. Only when a full inline create or edit form is submitted is data ignored. Sadly, of course, this is the primary creation UI for new contacts.

Would it be helfpul to switch the display method to 'tab' for an affected custom group?

Thanks, Deepak. It's a new site install, so it's not the end of the world for us to change the name of the sub-type and use something else, so I will try that in a fresh install and let you know shortly.

Thanks for verifying. Filed an issue here - http://issues.civicrm.org/jira/browse/CRM-11118.

Hello there,
I'm having the same issue with regards to saving data in custom fields. If I save in the general edit screen, It sometimes saves them, sometimes not, behaves very strangely (I am talking about one of the two advanced multiple select list fields). The other one in the same group works normally.

Very strange, and I do not even have any name conflicts - no Contact sub-type.

Any ideas?

Thanks!

Danny