Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-21144

CRM-20007 brakes potential changes done in "pre" hook

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 4.7.17
    • Fix Version/s: None
    • Component/s: CiviContribute
    • Labels:
      None
    • Versioning Impact:
      None (no code merged)
    • Documentation Required?:
      None
    • Funding Source:
      Needs Funding
    • Verified?:
      No

      Description

      A customization we had done for a customer had payment_instrument subdivided into MC/VISA/Amex.  This was done through a hook that would change payment_instrument to be that of a more specific value. Something like:

      function tools_civicrm_pre($op, $objectName, $objectId, &$objectRef) {
        if ("create" == "$op" && "Contribution" == "$objectName") {
          $objectRef['payment_instrument_id'] = ...
        ...
      

      Changes related to CRM-20007 broke this customization. Specifically, this subtle change in BAO/Contribution.php, ignores any manipulations done to objectRef.
       

      if (empty($contributionParams['payment_instrument_id']) && isset($contribution->_relatedObjects['paymentProcessor']['payment_instrument_id'])) {
      $contributionParams['payment_instrument_id'] = $contribution->_relatedObjects['paymentProcessor']['payment_instrument_id'];
      }
      

      Now this might be moot, since there are other changes that now make it possible to capture "card type" using a different approach. However, I am logging this, along with a few other change requests (yet to come), because the "card type" changes are still missing some functionality to make them fully usable from this customer's perspective. More specifically the ability to include the card type (& less importantly pan truncation) in:

      • batch transaction reports
      • in contribution view
      • in receipts, by including it in the template assignable values – though a customization would likely continue to be required for this as payment_instrument was never available to start.

      So the main point of this defect, isn't necessarily finding an alternate solution to record "card type", but rather that values changed through hooks shouldn't be ignored.

      Steps to Reproduce:

      • Create payment processor with a payment type of "CreditCard" (1)
      • Create a hook that changes payment_instrument to "Foo" (29)
      • Create a new online membership.

      Expected Result
      Payment instrument appears as "Foo" (29).

      Actual Result
      Payment instrument appears as "CreditCard" (1). Furthermore, careful investigation reveals that when SQL Transactions are turned off (I do this by temporarily commenting out methods in Transaction.php), Payment instrument temporarily appears as "Foo" (29), and is then is immediately set back to "CreditCard" (1).

      Regardless of the legitimacy of the use case given, we simply should not ignore potential changes done through pre hooks.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              litespeedmarc Marc Brazeau
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: