CiviCRM Community Forums (archive)

I suspect we are testing two different issues. The missing feature can be summarized as: "custom data is not saved for participant with paypal standard, and exposed via profile, IF the user enters it during online registration"

I just reverified this on demo. You can view the participant record and edit/save on demo and that will work fine. Its the "online reg" part that does not work

lobo

Arrrrgh. I've just come across this thread and this is a major spanner in the works for a site I'm planning to launch - to the extent that we'll have to get a Paypal Pro account to make things work.

However, I've got another related problem, and I'm seeking some clarification on this.

My events will have two profiles to be completed with the online registration.
1) General Name/Address details. (Top)
2) Custom fields particular to the event. (Bottom)

The custom fields are for participants

Problem 1
If I'm Admin the Custom fields profile appears, but for other users the only get the first profile to complete. Any ideas? I've tried the sandbox, and it seems to work fine - but that is also an Admin account!

Problem 2
Having read this thread, my understanding is:
1) If the custom fields appear, the data entered by the user will be lost if the payment system is not paypal pro or authorize?
2) If the event is free - no payment information, does the custom data still get discarded?
3) With these problems, is there an easier way to capture this data later? For example, user pays through the event registration system and then later adds their additional details. Can I implement a workaround on this? 

Thanks, Stephen

Hmmm, this has rather put a spanner in the works.   

I'm a little confused as to why the custom data should be lost - is all of the data from the form passed to the payment system and hence it doesn't get passed back? If so, this surprises me that it isn't just saved (temporarily) before the checkout stage.

Would a standalone form be of any help?

> 3. Unfortunately we dont expose participant fields to be viewed/edited at a later stage (primarily due to
> the 1 -> n relationship between contact and participant). So i dont think a workaround is trivial.

I'm not sure why 1 -> n makes it so hard. I don't know the inside of CiviCRM, but as a basic principle: query for all events with the user, produce list of events, 'edit' option for each event brings up the profile form used when originally signing up to the event?

I think the most important issue here is that the instructions in the backend need to be more clear. They need to say very clearly that you should NOT DO THIS if you are not using the specific payment processors.  Maybe what you could do is have a linkback to a list of payment processors for which custom fields will work. That way if someone does write something for a new payment processor the list can be updated easily.

I've added a warning to the custom fields doc. Please feel free to add/modify if you think you can make it clearer. I've just listed to the 2 processors that DON'T work as they are the exception (they don't provide a direct API for post payment/get results).

http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=9307

The below questions are better answered on IRC. You might want to read http://civicrm.org/architecture/ to get a better idea of the layout of the application and structure. Having a good knowledge of PHP and OOP constructs help a lot

Using paypal pro or authorize.net as your payment processor might be a cheaper / faster solution in the short term

lobo

The profile: http://drupal.demo.civicrm.org/civicrm/admin/uf/group/field?reset=1&action=browse&gid=8

is empty. So not sure what you expect to "show up" in the form for an empty profile. It does work in 2.0 (i think we fixed this for 1.9)

Note that a profile is different from a custom data group. You will need to add the elements from ypur custom group here:

http://drupal.demo.civicrm.org/civicrm/admin/custom/group/field?reset=1&action=browse&gid=6

to the profile in the first link. Please check and read the docs to get a better idea of the differences (http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=9295)

lobo



lobo

I think this means that the warning in the doc is now out of date:

Custom Contribution and Participant Fields NOT Supported for Some Payment Processors

found in:

http://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=9307