Some changes to a civicrm contact are refusing to save in certain circumstances when this plugin is installed.
General prerequisites:
This extension must be installed and configured with one or more synched groups.
The contact must be lacking membership in any of the CiviCRM groups configured for sync according to the rules at /administrator/index.php?option=com_civigroupsync&view=synchronizationrules , and then any of the following scenarios can be performed to experience the described bad behavior.
Circumstances:
As described in #10: adding / removing of Groups for a contact is predictably refusing to save in civicrm under certain predictable conditions.
When a contact's uf_match.uf_name value (generally the corresponding Joomla user's email address) is not an exact case-sensitive match for the contact's primary email address; then any code execution path that includes CRM_Core_BAO_UFMatch::updateUFName() (e.g., saving the Contact Edit form, use of the contact.create api, etc.) will silently fail to save the given changes.
This appears to be caused by behavior at this line in plgSystemCiviGroupSyncLCD::onUserAfterSave(). This loop calls the groupContact.delete api for each synched Joomla/CiviCRM group, if the relevant Joomla user is not a member of that group -- even if the relevant CiviCRM contact is already not a member of that group, which is a case that will generate an error in the api ("Cannot Delete GroupContact"), and which also causes a database transaction rollback, thus reverting (refusing to save) all submitted parameters for the contact, along with any other SQL queries that were executed in that database transaction.
The solution appears to be first checking that the groupContact record exists, using groupContact.get, before attempting to delete it with groupContact.delete.
Some changes to a civicrm contact are refusing to save in certain circumstances when this plugin is installed.
General prerequisites:
Circumstances:
CRM_Core_BAO_UFMatch::updateUFName()
(e.g., saving the Contact Edit form, use of the contact.create api, etc.) will silently fail to save the given changes.This appears to be caused by behavior at this line in
plgSystemCiviGroupSyncLCD::onUserAfterSave()
. This loop calls thegroupContact.delete
api for each synched Joomla/CiviCRM group, if the relevant Joomla user is not a member of that group -- even if the relevant CiviCRM contact is already not a member of that group, which is a case that will generate an error in the api ("Cannot Delete GroupContact"), and which also causes a database transaction rollback, thus reverting (refusing to save) all submitted parameters for the contact, along with any other SQL queries that were executed in that database transaction.The solution appears to be first checking that the groupContact record exists, using
groupContact.get
, before attempting to delete it withgroupContact.delete
.PR forthcoming.