Online contributions register, membership renewal fails

[mariagwyn]

I have a problem with online membership renewals.  On my drupal site, members who are EXPIRED in Civi are allowed to renew their memberships online.  They have access to the contribution form, and can successfully enter their information (which includes two civi profiles), enter credit card, and pay.  On the civi side, the payment goes through (IATS), the contribution is registered, but the membership is not.  According to my developer friend, a 'access denied' error is being thrown, even though it is not in the logs or screen.  The newly renewed member gets no receipt.

However, if a CURRENT member does the same process, everything works fine, as it does on the admin side.

This is a puzzle and a major problem on our site.  The relevant drupal roles are 'Current' and simply the authenticated user.  When a civi membership expires, the drupal account is no longer 'current'.  But there is no place in Civi that I can give access to one type of drupal user but not another.  Drupal permissions all seem to make sense as well.  So, I am mystified and my users are not able to renew easily.

Help!
Maria

[joanne]

Did you ever work out what was wrong as I am having this problem also?

[flug]

I'm getting this also.  The situation I'm getting it is where the user is not logged in.  They fill out the contribution form (a price set that includes both membership and other contributions) and when they submit, the contribution is recorded correctly to their contact record (via auto-match) but the membership is not recorded.

The error is in the watchdog log and looks like this:

Code: [Select]

Type access denied
Date Wednesday, October 24, 2012 - 1:18am
User Anonymous
Location http://ourwebsite.com/civicrm/admin/contribute?reset=1
Referrer
Message civicrm/admin/contribute
Severity warning
However, I'm not sure this error always occurs.  When I tried to test the problem, I received this error.  However when a 'real' user had the similar problem, no error was recorded.

I'm pretty sure this is a bug and we just need to report it and get it tracked down.

I don't see anything similar to this reported in JIRA.

[Donald Lobo]

In addition to reporting the bug, you should take the next step and see if you can figure out what is broken and why and  work on a patch for it.

Things are a lot more likely to get fixed and improved if there is a patch and test attached.

lobo

[flug]

I'm getting this also.  The situation I'm getting it is where the user is not logged in.

OK, more info.  I'm afraid this is beyond what I can figure out a patch for, but there is some pretty solid info for those who understand some of the DB intricacies better:

• It happens when an existing but expired member enters a membership renewal via the contribution page with a price set (might happen in other circumstances, such as a contribution page without a price set, but the price set example is the one I have tested.
• It also happens with test contributions, so you can test easily
• It happens whenever the end date for the membership you are trying to renew is before the current date.
• I have been testing in the case where the user is not logged in but I don't think it makes any difference whether the user is logged in or not.
  
• The problems appears to be caused by the invocation of $transaction = new CRM_Core_Transaction(); in CRM_Member_BAO_Membership::create (about line 320). If that line and other references to $transaction are removed everything seems to work AOK--the membership and contribution are recorded successfully.  So maybe something about $transaction->commit is not working in this case?
  

As a kludgy fix to the problem you could remark out three lines in function CRM_Member_BAO_Membership::create() in civicrm/CRM/Member/BAO/Membership.php:

  * $transaction = new CRM_Core_Transaction();
  * $transaction->rollback();
  * $transaction->commit();

You lose the ability to rollback in the middle of the transaction if there is an error (and thus you might end up with some partial/incomplete transactions recorded, ie the membership recorded but not the contribution, or something along those lines, if there is an error or interrupted transaction).  But at least the membership is recorded!

More details:

 * The function CRM_Member_BAO_Membership::create() calls CRM_Member_BAO_Membership::add() with the correct values in $membership.

 * CRM_Member_BAO_Membership::add() calls $membership->save(); with the correct values in $membership

 * No error is returned in either place--the $membership object doesn't indicate that any error occurred.

 * $transaction->rollback() is NOT called and $transaction->commit() IS called, in about line 430 of CRM_Member_BAO_Membership::create().   So I think it is more of a subtle error involving the $transaction object rather than a simple coding mistake.

Here is a backtrace from the point of the $membership->save() call just FYI:

#0 CRM_Core_Error::debug(backTrace, #0 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Member/BAO/Membership.php(110): CRM_Core_Error::backtrace() #1 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Member/BAO/Membership.php(342): CRM_Member_BAO_Membership::add((Array:11), (Array:2)) #2 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Member/BAO/Membership.php(1837): CRM_Member_BAO_Membership::create((Array:11), (Array:2), FALSE, "Membership Renewal") #3 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Member/BAO/Membership.php(1385): CRM_Member_BAO_Membership::renewMembership("19212", "12", 1, Object(CRM_Contribute_Form_Contribution_Confirm), NULL, "19212", (Array:0)) #4 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Contribute/Form/Contribution/Confirm.php(898): CRM_Member_BAO_Membership->postProcessMembership((Array:58), "19212", Object(CRM_Contribute_Form_Contribution_Confirm), (Array:47), (Array:0), (Array:0)) #5 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Contribute/Form/Contribution/Main.php(1423): CRM_Contribute_Form_Contribution_Confirm->postProcess() #6 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Core/Form.php(246): CRM_Contribute_Form_Contribution_Main->postProcess() #7 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Upload.php(151): CRM_Core_Form->mainProcess() #8 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Upload.php(128): CRM_Core_QuickForm_Action_Upload->realPerform(Object(CRM_Contribute_Form_Contribution_Main), "upload") #9 /home/ourwebsite/www/www/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Upload->perform(Object(CRM_Contribute_Form_Contribution_Main), "upload") #10 /home/ourwebsite/www/www/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "upload") #11 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Core/Controller.php(289): HTML_QuickForm_Page->handle("upload") #12 /home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php(228): CRM_Core_Controller->run((Array:3), NULL) #13 /home/ourwebsite/www/www/sites/all/modules/civicrm/drupal/civicrm.module(382): CRM_Core_Invoke::invoke((Array:3)) #14 [internal function](): civicrm_invoke("contribute", "transact") #15 /home/ourwebsite/www/www/includes/menu.inc(350): call_user_func_array("civicrm_invoke", (Array:2)) #16 /home/ourwebsite/www/www/index.php(17): menu_execute_active_handler() #17 {main} ) called at [/home/ourwebsite/www/www/sites/all/modules/civicrm/CRM/Core/Error.php:496]

[Dave Greenberg]

I was able to recreate this on the 4.2 drupal demo. The bug does seem to be restricted to anonymous (not logged in) flow. You can track the issue here:

http://issues.civicrm.org/jira/browse/CRM-11149

Will be helpful if you can grab a patch and test on your install once we have a fix.

[Yashodha Chaku]

We have fixed this for 4.2.5. Here is the patch :
https://fisheye2.atlassian.com/changelog/CiviCRM?cs=43283

HTH
-Yashodha

[nirajsingh]

I am facing same problems on Joomla 2.5 and CiviCRM 4.2.4.

Will really appreciate any help.

Thanks,
Regards,

Niraj
www.itaaworld.org

[Dave Greenberg]

The issue is fixed in the latest stable release - 4.2.6. So you can either upgrade or apply the patch as noted by Yashodha.