CiviCRM Community Forums (archive)

I recently added a custom field to my contribution entity.  The custom field has no default and it's used to classify individual contributions manually after they have been processed.

Shortly after I set this up, I was surprised to find out that a new recurring contribution had a value for this field.  Upon inspecting the code, I found the copyCustomValues function in the CRM_Core_Payment_BaseIPN module that uses the initial recurring contribution in a series as a template for all future recurring contributions in that series.  I had set a value for the initial contribution and this module copied that value to the new contribution. Given what I'm using this field for, this is an undesirable behavior.

Apparently this is a new feature added in the last year or two.  Having read through various forums, the prior releases of Civi that didn't copy the custom field values caused problems for people who wanted their custom values copied.

Architecturally, I'm not sure using the first completed contribution as the model is the best approach.

My "feature request and suggestion" is to store the model elsewhere, tied to the appropriate entry in civicrm_contribution_recur.  Once that is done, the first occurrence of a recurring transaction won't be a special case any more.  Perhaps the model could still be stored in the civicrm_contributions table, but separated from "real" contributions with a "is_recur_model" flag.

Clicking the recurring contribution view/edit links would allow the user to change the model for future contributions, without having to change completed contributions.