search

ChrisChinchilla / CiviCRM-eWay-recurring-payment-processor

CiviCRM eWay recurring payment processor
https://github.com/henare/CiviCRM-eWay-recurring-payment-processor#readme
0 stars 4 forks source link

Contribution custom data #21

Closed kenwest closed 9 years ago

kenwest commented 10 years ago

When custom data is associated with contributions, and a recurring payment is made, the current behaviour is ...

  1. the custom data fields are presented to the end user (subject to visibility rules)
  2. the custom data is recorded against the first contribution
  3. the custom data is not recorded against the recurring contribution
  4. the custom data is not recorded against the subsequent contributions

The issue is that custom data becomes hard to find over time. (Imagine seeing a contribution from a long-term donor: to see the custom data I need to find the recurring contribution for that, then find the first contribution.)

My questions are ...

  1. No questions here
  2. Perhaps a solution is a custom report?
  3. Can the custom data be stored against the recurring contribution? Is that a core issue or one that can be solved for this payment processor?
  4. I assume we can copy the custom data to new contributions as they're made, but I think there's a visibility issue here: we can probably safely copy custom data that was visible to the end user ("What is the purpose of your donation?") but not necessarily non-visible data (which might be used for processing individual payments). Thoughts?
eileenmcnaughton commented 9 years ago

I think the PR to use the repeat_transaction api should help here. The repeat_transaction api uses the same contribution copy logic that is used in the base ipn class in core (ie. uses it, not copies it)

kenwest commented 9 years ago

Eileen, the Repeat Transaction API does the trick here.