2

After upgrading from 4.6.x to 5.7.3 staff is finding that many records can no longer be merged -> error:

#1 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Utils/Type.php(554): CRM_Core_Error::fatal("One of parameters  (value: Email) is not of the type Integer")
#2 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Core/DAO.php(1517): CRM_Utils_Type::validate("Email", "Integer")
#3 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Core/DAO.php(1481): CRM_Core_DAO::composeQuery("\n                        SELECT v.label\n 
5

So I looked at the civicrm email records of the two contacts that produce such an error and they look fine.

Alan figured out that this is a bug: during the merge process when data is being gathered about both contacts, code is verifying that the value is valid, but it does so after converting it to an option value (i.e. email is "2").

A quick workaround for those struggling with the same issue - remove Preferred Method Email from Contacts. For this client this field is no longer used so we could just:

update civicrm_contact set preferred_communication_method=NULL where preferred_communication_method=2;

Merges are working again - phew!

1

For anyone else landing here I was having a similar problem, but my client is actively using the preferred_communication_method in their workflow.

KarinG's answer pointed me in a direction that seems right and definitely works for me, with the issue being that the preferred_communication_method is treated as an array, and it looks to me like the error encountered in merging is due to code in the merge process that tries to explode the array and work with it.

This led me via an answer at https://stackoverflow.com/questions/47266517/civicrm-crm-core-daovalue-separator-how-to-use-it-in-pure-sql to this immediate solution which lets the client keep using the field and have merges work correctly:

update civicrm_contact set preferred_communication_method=concat(X'01',2,X'01') where preferred_communication_method=2;

-with X'01' being the CRM_Core_DAO::VALUE_SEPARATOR

With this enacted (obviously for all relevant Integer values in addition to 2), all is fine.

Further note: in my case the reason the fields had an integer instead of an array to begin with is a module I have for taking live input from another CRM system. My next task is to fix this module (which uses the Civi API, not raw SQL) to populate this field with an array as expected. Edit: On further research it was my use of the APIv3, which allows entering and will update with a string value, causing the merge problem. The solution is to ensure passing an array for preferred_communication_method. My updated API call is now of the form

$result = civicrm_api3('Contact', 'create', array(
  'contact_type' => "Individual",
  'id' => $cid,
  'preferred_communication_method' => array($pcm),
));
New contributor
AlexT is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

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.