CiviCRM Community Forums (archive)

VERSION:
3.0.3

ERROR:
Sorry. A non-recoverable error has occurred.
One of parameters (value: ) is not of the type Integer


CAUSE:
It seems that there is a scenario where the $membership variable located within postProcessMembership is not assign, as such there is another call to CRM_Core_BAO_CustomValueTable::postProcess that is expecting a valid $membership variable, and since it does not, results in an error.

RESOLUTION:
I was able to avoid the non-recoverable error, and correctly obtain a transaction denied error, if I add an if wrapper as outlined below, BUT was wondering if anyone else has seen this issue? AND can someone more experienced with CiviCRM confirm if the fix below is technically correct for CiviCRM, I am fairly new to CiviCRM and while this seems valid, I am not sure if I would be impacting some other execution path.

        if ( ! CRM_Utils_Array::value( $index, $errors ) ) {
                        $membership = self::renewMembership( $contactID, $membershipTypeID,
                                                 $isTest, $form, null,
                                                 CRM_Utils_Array::value( 'cms_contactID', $membershipParams ) );
            if ( isset( $contribution[$index] ) ) {
                //insert payment record
                require_once 'CRM/Member/DAO/MembershipPayment.php';
                $dao =& new CRM_Member_DAO_MembershipPayment();   
                $dao->membership_id   = $membership->id;
                $dao->contribution_id = $contribution[$index]->id;
                //Fixed for avoiding duplicate entry error when user goes
                //back and forward during payment mode is notify
                if ( !$dao->find(true) ) {
                    $dao->save();
                }
            }
        }
   
// ADDED  the !empty if check for membership around postProcess, since membership was never assigned because of transaction failure (denial)
      if (!empty($membership))
      {
              require_once 'CRM/Core/BAO/CustomValueTable.php';
              CRM_Core_BAO_CustomValueTable::postProcess( $form->_params,
                                                          CRM_Core_DAO::$_nullArray,
                                                          'civicrm_membership',
                                                          $membership->id,
                                                          'Membership' );
      }       

It appears that I was able to reproduce this scenario when the following conditions where involved:

1) Login as default drupal admin account

2) Enable membership dues payment option for my default contribution (donation) pages

3) Attempt to submit a member dues payment along with my contribution.

Since the default admin account was not associated with a civiCRM member/contact, there was no valid id available upon processing.

I will look for additional information as I have time, hopefully the above is enough to give you a reproducible scenario.

Interesting, well that might be the issue. I do not see a contact for my main admin root account. Even if I logout and back in. Is this "root" drupal admin a possible exception to the rule? I really have no other idea, what it might be.

As I mentioned before, I am fairly new to CiviCRM so I was hoping to get some insight since I agree it seems odd. But I really have no time nor enough knowledge to specifically track it down (maybe once I complete this crazy project I am working on!?!?)

With that said, as a good coding practice, I would say that the added IF statement might still be valid, assuming it does not alter the execution path. Since the code being called is blinding using the input data, assuming it is valid.  So would it really be an issue to protect that code with this or a similar if check, before calling?

Again, I have no knowledge of this code base, so if the plan is to leave it "as is" that is fine. Since I am going to assume my issue is a rarity, and if I have time to focus on determining a specific method to reproduce I will post about it, eventually.