Use CiviCRM API v3 for compatability with v4.3.x+

I am running
Drupal 7.22
Civicrm 4.3.1
Commerce_civicrm 7.x-1.0-beta1
Commerce 7.x-1.5

I am very much a novice but I had this error. It appears to me that the latest version of civicrm retired the table called civicrm_contribution_type. There are two tables I suspect it needs to refer to - civicrm_financial_account
and civicrm_financial_type. Don't really know which one it should be but per this article, I chose civicrm_financial account. http://issues.civicrm.org/jira/browse/CRM-8425

I updated the code in commerce_civicrm.module line 260

$sql = "SELECT id, name FROM civicrm_financial_account WHERE is_active = 1";

And the /admin/commerce/config/civicrm url worked and allowed me to assign event fees as the contiribution type and select my group from civi to add these customers to. Seems to work fine.

I am gathering this is probably the issue that I am running into as well. Everything was working fine and then we updated to CiviCRM 4.3.1. Now I am getting this error when I try to view a person's record:

Sorry but we are not able to provide this at the moment.
Unknown data property commerce_customer_address.

Changing to bug report, since I believe CiviCRM 4.3.x is necessary now for security.

I'd love to use this module too... any chance of somebody coming up with a patch?

-Joseph

Yes, I believe you are right about security. I've had to turn the module off for the moment, but I have to get it back up in the next few days.

As this bug makes the module unusable with the current version of Civicrm, setting this to critical.

So does the fix described by spireinstitute work for others, or are there still problems with this module and CiviCRM 4.3.x?

Initial testing of the fix by spireinstitute works for me.

I'm working on a site that has Commerce and CiviCRM. Integration would be fantastic but I'm hesitant to install with this issue unresolved.

we are working on this now - hoping we aren't duplicating what others are done - 155 changes so far to get it to API 3 so not sure how #1 got there
hopefully more to report tomorrow

This patch *mostly* uses API v3. Has at least one SQL query remaining due to lack of API support for financial type lookup.

So based on the above, and some v quick testing - and please help test and document

For logged in user.

Commerce NAME: does not prefill but does push to civi hence overwriting existing name

Commerce ADDRESS fields do not prefill but do push data to civi, creating additional Billing Address

PURCHASES Tab is created and updated with link to the Order

CONTRIBUTION record is created if set at /admin/commerce/config/civicrm

GROUP is created if set at /admin/commerce/config/civicrm (but only if Contrib is also set it seems)

SOURCE is set to Drupal Commerce for existing records

so seems like there is a fair bit to sort out still

To be clear, is this patch against the beta release or the dev release?

Ran the patch against the beta1 release and got the following:

$ patch < commerce_civicrm-1975106-civicrm_api_v3.patch
patching file commerce_civicrm.module
Hunk #1 succeeded at 48 (offset -8 lines).
Hunk #2 succeeded at 59 (offset -8 lines).
Hunk #3 succeeded at 67 with fuzz 2 (offset -8 lines).
Hunk #4 succeeded at 94 with fuzz 2 (offset -20 lines).
Hunk #5 succeeded at 140 with fuzz 2 (offset 14 lines).
Hunk #6 succeeded at 175 with fuzz 2 (offset 30 lines).
Hunk #7 FAILED at 190.
Hunk #8 succeeded at 241 with fuzz 2 (offset 37 lines).
Hunk #9 succeeded at 373 with fuzz 2 (offset 145 lines).
Hunk #10 FAILED at 380.
Hunk #11 succeeded at 431 with fuzz 2 (offset 151 lines).
Hunk #12 succeeded at 509 with fuzz 2 (offset 199 lines).
Hunk #13 FAILED at 516.
Hunk #14 FAILED at 554.
Hunk #15 FAILED at 708.
Hunk #16 FAILED at 728.
Hunk #17 FAILED at 827.
Hunk #18 succeeded at 556 (offset -139 lines).
Hunk #19 succeeded at 588 (offset -139 lines).
Hunk #20 succeeded at 722 with fuzz 2 (offset -59 lines).
7 out of 20 hunks FAILED -- saving rejects to file commerce_civicrm.module.rej

Ran it against the dev version and it looked to go without a hitch, so I'm guessing the patch is against the dev version and not the beta1 version. Anyone care to confirm?

yes patch against Dev

Thanks for the confirmation petednz. I'm running CiviCRM 4.4.2 on a D7 Commerce Kickstart Drupal profile, and seeing the following PHP notice:
Notice: Undefined index: cid in commerce_civicrm_civicrm_links() (line 96 of /home/sites/all/modules/commerce_civicrm/commerce_civicrm.module).

@Upperholme, that 'undefined index cid' issue is #1896906: Notice: Undefined index: cid in commerce_civicrm_form_commerce_order_ui_order_form_alter() (line 129 of commerce_civicrm.module), looks like the patch there may need re-rolling to apply also to commerce_civicrm.module@100.

I first tried to use this module on a site where we had CiviCRM 4.2.2 installed. I was rather disappointed that it didn't work. I tried both the stable release and the dev version and neither worked. I then tried this, and it definitely did not work. Upon further investigation, it seems like many of the API functions used here are added in CiviCRM 4.3.x, so I think I will have to update to that before I can do a full test of this. But thanks in advance for everyone's work on this!

This commit does work better with CiviCRM 4.3.x (thanks to their APIv3), but it does have a number of issues. It seems to add a large number of addresses from the order, many of which don't have a type label set correctly. But it's better than nothing working at all.

dandaman - it would help if you can provide some more explicit documentation on what these addresses are - under what circumstances they are created or not - and what Location Type they do get given.

I'll have to test it further, petednz. At this point the site we have CiviCRM running on is using an old version of Commerce Kickstart and I've had some problems upgrading Commerce Kickstart, so it could be that some of the Commerce code you're using doesn't work as well with the older version I'm using. I'll try to take a look at it further and get back to you.

The patch against 7.x-1.x

It would be nice to get this in. Not sure about all the try catch statements, in my experience when Civi errors out it prints an error message and then exits so you'll never get to the catch part in any case.

CiviCRM API *should* throw exceptions when it hits errors in 4.3.

I think starting from CiviCRM API v3? May inconsistently throw Exception, API_Exception or CiviCRM_API_Exception, but they all are exceptions. Vaguely related issue for UC CiviCRM @ #2186523: Handle exceptions & errors consistently.

I tend to think that try catch is an anti-pattern, but I think I'm seeing a bigger issue with the patch. I'm getting a function not found error for civicrm_api3(). Any particular reason to use this over something like

  $event_get = civicrm_api('event', 'get', array(
    'event_id' => $event_id,
    'version' => 3,
  ));

Should be identical functionality I assume?

Yes. If successful the API result should be the same, on failure civicrm_api() returns a CiviCRM-style error and civicrm_api3() throws an exception.

Exceptions pattern seems optional (CRM-13016) but we've moved this way since it's CiviCRM's standard approach for v3 API usage (api/v3/examples, Developer guide on API techniques).

Looks like the test suite uses civicrm_api() instead of civicrm_api3(), so both approaches should be OK. De gustibus non est disputandum. :)

We are running Civicrm 4.4.3 and Drupal 7.x

Tried running the patch (https://www.drupal.org/files/issues/1975106-23-API-v3-for-compatability....) against the dev version as suggested but got this error
patching file commerce_civicrm.module
Hunk #2 succeeded at 67 with fuzz 1.
Hunk #6 succeeded at 163 with fuzz 1 (offset 18 lines).
Hunk #7 FAILED at 160.
Hunk #8 succeeded at 220 (offset 18 lines).
Hunk #9 succeeded at 244 (offset 18 lines).
Hunk #10 succeeded at 251 (offset 18 lines).
Hunk #11 succeeded at 296 (offset 18 lines).
Hunk #12 succeeded at 367 with fuzz 2 (offset 59 lines).
Hunk #13 FAILED at 315.
Hunk #14 FAILED at 348.
Hunk #15 succeeded at 536 (offset 46 lines).
Hunk #16 succeeded at 556 with fuzz 2 (offset 46 lines).
Hunk #17 FAILED at 609.
Hunk #18 succeeded at 721 (offset 44 lines).
Hunk #19 succeeded at 749 (offset 40 lines).
Hunk #20 succeeded at 803 (offset 40 lines).
4 out of 20 hunks FAILED -- saving rejects to file commerce_civicrm.module.rej

Thanks Vishram. The patch doesn't apply because other fixes have been committed the months since it was uploaded. Unfortunate that no-one was able to take time to review it, esp since there are 16 people following this issue. Hopefully someone (perhaps yourself?) will be able to update the patch and provide some feedback on it.

As you'll see from the patch output above, most of the patch has applied, but patch needs some help to understand what to do at certain places. There's a .rej file which contains all the bits that didn't work.

Attached is a modified version of the patch from #23 that now applies against current dev. Code does not work - throws an error when viewing the config page at admin/commerce/config/civicrm:

Fatal error: Call to undefined function civicrm_api3() in commerce_civicrm/commerce_civicrm.module on line 270

Looking at it further, it seems that the civicrm_api3 function was added in version 4.3.5 (see https://issues.civicrm.org/jira/browse/CRM-13016). I tested this on version 4.3.3

Can anyone test on 4.3.5+ to see if the module will work with this patch applied?

Added the patch from https://github.com/civicrm/civicrm-core/commit/6b359437509fdc0339c0f921f... to CiviCRM 4.3.3 (its just a wrapper) and the module config page now works. Hopefully the rest of the module will work.

Many thanks for this work ac. I'll give it a spin and see what occurs.

Just a heads up, I think this module could do with some more co-maintainers. I'm not working on any CiviCRM sites any more so I don't have the ability to check any patches work, and the module owner Stella hasn't made any commits for 2 years.

muhleder - yep agree - I may be getting modules confused but pretty sure we (xurizaemon and eileenm) have already reached out - and have done a lot of work on this so will discuss precipitating further

Can confirm that the current dev with the patch in #31 applied works as expected on CiviCRM 4.4.8. Would be great to get this committed and a release pushed as currently it is a bit of a pain to maintain.

Does #31 patch make this module with with CiviCRM 4.5.4 ?

@slavojzizek, please test and report back to other module users with your results? The patch may have got stale in the ~9 months between now and its original submission.

If you install Dreditor browser extension, you'll find it trivial to test whether patches apply via simplytest.me. IDK how you'd go getting SimplyTest.me to install CiviCRM but it'll definitely help you with more standard Drupal modules :D

@ac in #31 you say the patch attached has an error on the config screen, but in #37 you say the patch from #31 is RTBC? It's possible both of these are true, if CiviCRM started autoloading civicrm_api3 function in the meantime, but just checking since this sounds like there might still be work to do? EDIT: Oh look, #32 answers this? :)

patch #31 works more or less for me (drupal 7.34,CiviCRM 4.5.5) except that
- 6 addresses are created in civi ;-)
- I get an error
Notice: Undefined index: cid in commerce_civicrm_civicrm_links() (regel 100 van .../public/sites/all/modules/sandbox/commerce_civicrm/commerce_civicrm.module).
Willing to sponsor further development

Thanks for testing yichalal. Based on your feedback I'm marking this as "Needs work." If you do want to get this fixed up, you might need to do more than state your willingness here. Try contacting the module maintainers and if they don't respond, try some other CiviCRM developers who know Drupal. If you need help finding somebody, I'm happy to make some recommendations (nobody I know personally, just based on their other work I've seen.)

-Joseph

We've just made a patch that looks like it's working pretty well on Civi 4.5.4, Drupal 7.32, Commerce 1.9.
We're just documenting it properly now and will put it up soon.
Hope this helps!

By the way I'm happy to commit anything once you guys agree that it's RTBC, just send me a PM to let me know.

I created a patch to check for existing billing and shipping addresses and update them instead of creating new ones if they already exist. Also expanded phone number creation / update.

This solves the first problem in #41.

Setting civi employer based on commerce form field created duplicate employer contacts for me so I disabled it.

Working on Drupal 7.34, Civi 4.5.5, Commerce 1.10

Are there any outstanding issues with this patch? Looks like #41 is addressed by #45. How about beta3?

Patch from #45 changes my version of Commerce_CiviCRM from 7.x-1.0-beta2 to 7x-1.0-beta+40-dev, but seems to be mostly working. I can't view the Purchases tab, though; I get a network error.

I'm using CiviCRM 4.7.4, Drupal 7.43, and Commerce 1.11

+1 on this, is this working at all?

This has been fixed as a part of https://www.drupal.org/node/2806529