CiviCRM Community Forums (archive)

I've been trying to update a contribution in 3.0 using civicrm_contribution_add (below:  CCA).  After studying the test code used with CiviTest and running stuff through the debugger, I'm now reasonably certain that on update, the API likely has never really worked right, and that the test as devised in the test/ hierarchy does not test the right things to make the (as we'll see, multiple) problems with the API surface.

I'd put a report in JIRA, but I think really the problems are worse than that:  the implementation of the API needs to get code reviewed -- a simple fix won't fix the problems I'm about to list.

Here's is a partial list of the problems.  I actually do not  believe the list is complete.  It's only the problems I've found so far.  Most of these problems are in the wrapper file in api/v2/;  the update transaction will either fail outright or do the wrong thing unless you call it with a (really long) list of work-arounds.

Here's the damage so far:

• You need to specify the object's ID using 'id';  'contribution_id'  will be ignored.  I'm not sure if this is a bug or not, but I haven't found where it's documented either.
• While most of the CiviCRM v2 civicrm_XXXX_add()  type APIs will do an incremental, update -- as long as you include the ID of the item you're updating,  you can specify one or two fields and change only those fields. If you try this with CCA, you'll either fail because fields not needed to identify the object are actually required (see below),   or you will actually zero out any fields you did not explicitly specify with the update.  This is certain -- I can see that the contribution_id is unchanged, but any unspecified field is now either null or a default.
• The required fields for an update are bizarrely the same as those for a create.  The wrongly required fields include contact_id and total_amount.
• Since you can't not specify fields, you need use civicrm_contribution_get() to get the complete contact, modify what you need to modify, and pass this to CCA.  But this won't work unless you modify the following fields in CCG's output before passing them to CCA:
  
  • You need to change 'contribution_id'  to 'id'
  • The dates are in ISO format, which will choke CCA's field validator.  You need to change them to MySQL import format.
  • If you want to change the contribution_type_id (numeric) you actually want to change contribution_type (a pseudo-constant string), since the code only looks at contribution_type, ignoring contribution_type_id.
  • contribution_status_id is almost the opposite of contribution_type_id -- it gets passed by CCG to you in pseudo constant form (i.e., a completed transaction is passed to you as 'Completed',  but you need to look up the numerical equivalent (1) and overwrite the value of the string constant with the number.

These are only the problems I know about.  I found these by following the code through the debugger (don't ask how many times.  I don't know.  I lost count after around 10).

Looking at the test file, it's clear that the incremental change case is not checked, which is the only reason that CCA was not flagged as buggy months ago.

I'll put this into JIRA, but I suspect the problem here is that the work on CCA was not code reviewed properly, since these are a lot of problems to slip through into production.

I don't think many people have used this API successfully, but if you have, I'm curious to hear what you had to do in order to make it work well enough to trust it.  I did see one other note in the forums that suggest that the developer was running into some of the same problems I've described here.

hmm. not sure how this is related to civicrm_contribution_add, i suspect it is not

you mght want to start another forum topic on this. You mght also want to give some more background and suggestions on how things can be improved. Finally if you do have resources submitting patches to implement your suggestions would be great

lobo