Membership page gives error on user record instead of payment processor

[websynapse]

This is happening on our usual Join page, so I set up a new one to test.

I set up a new Contribution page with no customisation.

It records their details and shows the confirmation screen with the details on it. But instead of the payment processor screen, they get Access Denied.

If they are logged in with the appropriate permissions, they see their user record and this error message:

Code: [Select]

The membership cannot be saved.
No valid membership status for given dates.
Which dates are these? This has only happened since upgrading to 2.2

thanks.

[Dave Greenberg]

Check your Membership Status Rules under Administer CiviCRM >> CiviMember. It sounds like the default set of rules has been altered such that there is no status to assign for a membership that starts "today". In the default membership status rules - this would be assigned "New" status. Was that status deleted?

[websynapse]

No, the New status is right there, attached.

[Chris Burgess]

Hi Dave, thanks for the reply

So the issue is that after confirming their details on the second page of the contribute forms, the user is sent to their contact edit screen rather than the payment processor.

This causes an access denied (if they aren't logged in) or them to visit the contact record (if they are logged in and have permission to view the contact). But neither case is correct; they should be redirected here to the payment processor, then back to the thanks page.

I've tried the following steps to establish whether this is related to any of the custom code we're running:

• Switching to another payment processor
• Disabling our custom code path, so we're running just core CiviCRM 2.2.7
• Disabling all our custom Drupal modules, some of which interact with CiviCRM
• Disabling our custom templates

The issue persists through all these. The only components remaining are the core CiviCRM code and the site configuration in the DB; at this stage I have to assume it's the latter.

I'm currently debugging further, but would appreciate any input or suggestions!

Off now to find CiviCRM's redirect function to see if I can sneak a backtrace in it

Thanks

[Chris Burgess]

OK, looks like I've found what's stopping this working for us, though I haven't found a fix yet.

When the confirmation page is posted, we call (in this order):

• CRM_Core_Form::mainProcess()
• CRM_Contribute_Form_Contribution_Confirm::postProcess()
• CRM_Member_BAO_Membership::postProcessMembership()
• CRM_Member_BAO_Membership::renewMembership()
• CRM_Member_BAO_Membership::create()

This last function fails to create a new membership when no dates are provided for the membership.

When we create a new membership of this type, it has a status of pending, and therefore no date values are set around line 1162:1169 of CRM/Member/BAO/Membership.php. When we get to self::create() at line 1208, it fails to get a membership status from CRM_Member_BAO_MembershipStatus
::getMembershipStatusByDate() at line 220, and we get the redirect.

The error message "No valid membership status for given dates." is not displayed due to the access denied message when the un-authenticated user lands on the new contact view screen.

I'm not yet certain whether this is due to a configuration issue with our membership settings (I can't see anything yet, but this seems the most likely vector), or because some new code has sneaked in (perhaps with CRM-4555?).

[Dave Greenberg]

Chris - it does sound like the fixes to prevent "unpaid pay-later memberships" from being set to a valid current status might have messed things up for your setup. Can you reproduce the behavior you're seeing on the demo? Or if it's easier for you to just keep digging to find the bug ....

[Chris Burgess]

Will keep digging - couldn't reproduce easily on demo, and am better able to debug on my install.

[Chris Burgess]

Many debugging comments later, it turned out that somehow during the process from 2.0 to 2.2, we'd lost our Pending status.

I don't know if this was manually removed via the UI (shouldn't be possible as the status has is_reserved=1) or by some DB or other change.

But the result of this happening was as documented below - the person signing up for the membership would get redirected to their newly created contact edit screen if the payment processor set the status to pending.

Some questions arise about whether the processor should be able to set to a status which doesn't exist in the DB, or whether it should be possible to remove that status from the DB in the first place, but as I don't know the cause, and have spent WAY too much time tracing this problem back, I'm not going to go into them now.

Thanks Dave - ironically your first reply almost answered the question bang on, but it referred to the New status, and the payment processor had changed the status to Pending by the time this date calc happened.

[campsoupster]

Oh man, you saved my life with this find. I had no idea that Pending status would be the culprit. I hope other folks find this. After a few hours of debugging, I was giving up hope.

-sean

[Chris Burgess]

Thanks for letting us know that ours isn't the only site which had Pending status go AWOL.

@dgg, AFAIK it should be IMPOSSIBLE to remove the Pending status without DB tomfoolery. It is flagged as is_reserved and therefore should not display the "Edit/Delete" links. But it would seem that in at least two cases, the status has up and vanished for people.

@campsoupster, can you tell us a little more about your installation, so we can see what your site and mine might have in common? What version of CiviCRM? Was it upgraded? Any idea when the problem started or anything you associated with it (eg change of payment processor, membership reconfiguration, new signup page)?

(I did scour our log files looking for who to blame, but there were no guilty CiviCRM admins on our site.)

Our DB was upgraded from 2.0 => 2.1 => 2.2 recently, and it was sometime after that the issue started for us.

[Dave Greenberg]

Sean / Chris - any light that you can shed on possible cause would be great. I'm a bit suspicious that something in one of the upgrades led to this - but I don't see any obvious culprit glancing through the upgrade code / sql. I did note that the is_reserved flag for civicrm_membership_status table was introduced in v2.1 (didn't exist in 2.0).

[Chris Burgess]

Dave,

Not sure if it's related (I don't think it is, actually) but we also had to apply the patch in CRM-4523 to our v2.2 install because of other issues relating to membership statuses.

In that case, initially we were having the dates of memberships get knocked out when the pending membership was confirmed (reproduced on demo site) but applying the fix from SVN r21582 introduced an issue where we couldn't update a membership contribution status or membership status from pending.

I adjusted the change in r21582 and produced this patch against v2.2 which seems to be working correctly (it just excludes Pending from the statuses which are handled that way).

I would love it if this patch or a similar fix could be considered for 2.2.8, if it's correct.

[Dave Greenberg]

Chris - Not sure what the status of this is. Have you filed an issue with the new patch? If not, please do so.

On a related note, the code for handling "confirmation of pending membership" - from the Membership form (e.g. backoffice receives payment and marks it completed) has changed quite a bit in 3.0 - so not sure how you patch will "merge" with 3.0 code?? It will be important for you to test these flows in 3.0!

[Chris Burgess]

Hi Dave

Yes, there is an existing issue, CRM-4523. The patch I linked to against v2.2 was attached to the ticket http://issues.civicrm.org/jira/browse/CRM-4523

This issue appears on v2.2 if the current fix for CRM-4523 (r21582) is applied to v2.2. I'd link to the diff but JIRA is timing out again.

You can compare the result of this diff with the patch linked to in my previous post:

Code: [Select]

svn diff -r21581:21582 http://svn.civicrm.org/civicrm/trunk/

[Kiran Jagtap]

hi Chris,

since issue was fixed for trunk and now functionality is released w/ 3.0.alpha1.
If time permits, would be great if you test on 3.0.alpha1 or http://sandbox.civicrm.org/

more interestingly - If I am not wrong, the difference between code committed for issue and your given patch for  (CRM/Contribute/Form/Contribution.php  ) is
- if ( $currentMembership ) {
+if ( $currentMembership && $currentMembership['status_id'] != $pendingStatusID ) {

if we take a look for $currentMembership = CRM_Member_BAO_Membership::getContactMembership( );
which already excluding pending memberships ( line around 679 -  $dao->whereAdd( 'status_id != 5' ); )

so how pending membership comes in $currentMembership array ?
( did you change u r pending status id  ? )

I adjusted the change in r21582 and produced this patch against v2.2 which seems to be working correctly (it just excludes Pending from the statuses which are handled that way).

(if pending membership comes in $currentMembership array, to exclude these membership we should change at base level -
CRM/Member/BAO/Membership.php line around 679

$dao->whereAdd( 'status_id != 5' );  

to  

require_once 'CRM/Member/PseudoConstant.php';        
$pendingStatusId = array_search( 'Pending', CRM_Member_PseudoConstant::membershipStatus( ) );
$dao->whereAdd( "status_id != $pendingStatusId" );

)
(hope it make sense )

I have fixed this suspected bug. ( svn diff -r23208:23209 http://svn.civicrm.org/civicrm/trunk/ )

hope this help

thanks
kiran