mecachisenros / cf-civicrm

Caldera Forms CiviCRM Integration
GNU Affero General Public License v3.0
30 stars 26 forks source link

Plugin does not consider CiviCRM field limits and will attempt to submit data that exceeds the CiviCRM field data length #65

Closed agilewarealok closed 6 years ago

agilewarealok commented 6 years ago

CiviCRM refuses to process the submission with invalid data (e.g. Contact's first name greater then 64 characters) and Caldera does not respond to this error at all. The Caldera form will remain in a "submitting" state, with no feedback to the end user about the error.

Steps to reproduce

  1. Create a Caldera form with Two fields. First name and Last Name
  2. Add CiviCRM Contact processor in form and assign these two fields to contact's first name and last name in processor settings.
  3. Open the caldera form and submit the form with firstname and lastname where data in each field has more then 64 chatacters.
  4. CiviCRM thrown an exception which is not caught by the processor.
  5. Form remains in processing state and end user does not know about the error.

Our Approach to fix the issue

  1. Find all the places in processors where the data is getting saved in CiviCRM.
  2. Add the civicrm_api3 functions in try/catch block to catch the exceptions thrown from CiviCRM.
  3. Update the transdata global array with the error caught from exception and return from the processor.

Agileware is happy to contribute some time in fixing the issue.

mecachisenros commented 6 years ago

@agilewarealok Thank you for the great explanation.

May I ask what version of the integration are you using? What you mention I've already addressed, and most api calls to Civi are wrapped in try/catch block and moved the processing to the pre_processor callback where needed, see 7f340280fa08a3b2598578024b5e52dd653a17a2. The form processing stops and an error is displayed.

I'm unable to reproduce the error, see image attached. capture

agilewarealok commented 6 years ago

@mecachisenros Thank you for the reply. Yes it looks like it has been fixed in 0.4.3 and we're using 0.4.2 We will update the plugin from our end. Closing this issue as it has already been fixed in latest version.