Participant records aren't created when registering for event

[jtillman]

I'm at my wits end on this one.  Need help.

CiviCRM 1.9.13019, production site.  Drupal 5.2

I'm using Google Checkout with a CiviEvent event that uses several price sets.  I access the site as an anonymous user, fill out the registration pages, confirm, use Google Checkout to do a live transaction, and the CiviContribute record gets created as "pending".  However, no participant record is created.

Can someone help me troubleshoot this?  Time is of the essence right now.

j

[Donald Lobo]

1. you might want to check the forums for past posts on google checkout. most likely google is not calling you back and/or there is an error with processing the callback

2. if time is of the essence, you might want to consider hiring someone from our professional services list (http://civicrm.org/professional)

lobo

[jtillman]

I've been scouring the forums reading up on the Google Checkout issues and haven't found this issue discussed.  I'm fairly handy with PHP and CiviCRM (been working with both for a while), but this is my first outing with CiviEvent.

Google Checkout's integration console isn't reporting any errors in the callback.  This seems significant because previously it WAS reporting errors when I had a bad callback URL in the settings.

It would save me a great deal of digging through the code if someone could give me the play-by-play on the CiviEvent/Checkout interaction.  My main question is:  Are participant records created before the handoff to Google/Paypal?  This post makes me think that I should be seeing "pending" participant records, regardless of the callback from Google Checkout:

http://forum.civicrm.org/index.php/topic,432.msg1758.html#msg1758

Does Google Checkout's callback after charging the account cause the participant status to go from "pending" to something else?  Of course, I don't even have participant records of any kind (not even ones with null values as are mentioned in the referenced post), so I'm unsure where to go from here.

Any assistance that would help me figure out where to look for the problem would be appreciated.

jpt

[Dave Greenberg]

My recollection is that participant records are NOT created in 1.9 until the contribution is successfully completed - and I think this has been changed in 2.0 with the addition of the Pending status for civicrm_participant records.

If your contributions are still in Pending status - then it would seem that there is some issue w/ the callback.

I also did a quick search in the issue tracker and found this issue which may be relevant:

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

... it's "fixed for 2.0" but points to a suggested patch for 1.9 as well.
HTH

[jtillman]

The deeper I go into the code in 1.9, the more disappointed I become. 

There's some code in the Google Checkout modules that obviously never worked, and it's disheartening to see that it made it into a non-alpha release.

What's more, I'm just floored that someone would put all this functionality into the Event module for price sets and then completely neglect to set up the mechanism to retrieve a user's price set choices.  I'm making this statement based on what I've seen in the forum discussions about it.  So, even if it were working properly for me, it appears that I likely wouldn't have access to the price set information.  Why would you let someone input something on a form and then just throw away the data?  I see in the forums that 1.9 MAY have the capability to retrieve price sets via export or direct sql access, but I can't even test that because Google Checkout is just plain broke.

This is really different from my prior experience with CiviCRM.  Up to now, it's seemed to be a very well thought-out, carefully managed system.

[jtillman]

Oh, and the fix that was recommended doesn't seem to work.  A primary issue is that this code seems to be using the transaction_id of the contribution table to store what looks like the event id, but that column has a unique index on it (at least in my install it does). 

Maybe I'm not understanding it, but when something seems to be attempting to store "eid1" in that field, it looks like event id's to me.

[speleo]

Harsh words? As an open source project CiviCRM thrives on constructive feedback from it's users. I can understand that your disappointed with the inner workings of this functionality but there are ways of expressing this.

Many of us have found code which doesn't function properly and have provided clear pointers to where the problem might lie. This enables the devs to get under the hood and fix the issue.

[jtillman]

Point taken.  I hope my words aren't too harsh or unwarranted.  I don't believe they are.  I'm expressing disappointment, and a bit of frustration, in what seems like an appropriate place.  Better to voice them in the forums, since it's likely others are feeling them as well and just not bothering to say it (unless my needs are unique).

Don't get me wrong:  I'm gung ho about CiviCRM!  I wouldn't be spending the keystrokes otherwise 

I'm very tempted to just try the 2.0 alpha code because we need Event handling more than anything else, but this is a production site, so I'm worried.

Anyone monitoring this thread have any feedback on the stability of the latest 2.0 release on sourceforge?  Perhaps I should post in the new Alpha/Beta forum area to inquire...

[Donald Lobo]

I'd advise you to test on the sandbox and then deploy the 2.0 code base and ensure that it works as you expect / advertised. If not, please file an issue

The bug flow into the 2.0 issue queue has slowed down this week. we expect to be releasing a beta release very soon (later this week)

lobo