CiviCRM Community Forums (archive)

I'm looking at the fact that there are some contribution updates that have actions associated with them & wondering how that fits in our api model.

For example - there is a difference between updating a contribution to having a status of refunded or completed and refunding or completing the transaction. We currently have a specific action for completetransaction which, in addition to updating the status, also ensures related entities are updated and sends out confirmation emails. This leverages the actions taken when updating from IPN.

I'm fairly sure, however, that updating a transaction to cancelled or refunded does not trigger the business actions in the baseIPN class for that sort of transaction. We also would want having the ability to pass a refund request to the payment processor at some point.

So, at the very semantic level - we have said the action should always be 'create' with status_id  = 3 (e.g) but then we would be staring in the face of more magic params ('action_status_update_with_processor', 'send_emails', 'update_related_entities') since I'm not sure we can start adding that as std business logic.

Which leaves the other path of having things like 'recurring_contribution.cancel' as it's own action. Obviously the question is - where would it stop. At this stage it seems possible that we would have actions for change-of-status within reserved statuses.

Thoughts ? Is our current 'everything is a create' too brittle for more nuanced business logic?

Is it perhaps worth adding a new param to the API to indicate whether business logic actions should be run or not?  I realize that currently the actions taken may not be consistent, which means that this might be an API v4-focused suggestion.  It seems inevitable that support for both triggering and bypassing business logic will be needed for a variety of API activities. 

I can even think of some oddball cases right now - for instance, updating civicrm_address.master_id (for shared addresses) with an address that belongs to an organization triggers a function to set the Current Employer relationship.  Bypassing business logic would allow you to update the master_id without creating a relationship.