CRM-13233 Payment Method field (payment_processor) should not be required if total fee is $0

If you research this issue prior to demo site reset, you can find my version here: http://drupal.demo.civicrm.org/civicrm/event/register?reset=1&id=18

I don't pretend this is a suitable patch, nor do I have the skills or knowledge to offer a patch. But this is the jQuery workaround I am using for my installation. My workaround below, leaves display() unchanged for the time being, and relies simply on clicks. It lacks many things. But it seems like a possible solution is that when the display() function runs on the event reg page, a script similar to this is triggered. You are welcome to consider, re-use or adapt this code as you see fit.

<script>
cj("fieldset#priceset input").change(function() {
if (cj(this).attr('data-amount') == '0')

else

});
</script>

Stuart - This bug doesn't occur if the event only has a single payment processor enabled AND doesn't allow pay later. That's because the payment_processor fields is suppressed in that condition. You can also prevent the bug from affecting users if you set at least one of the payment processor options included for the event as the DEFAULT payment processor (From Administer > System Settings > Payment Processors). This forces that processor radio button to be pre-selected and hence the user isn't bothered with the form validation error (I realize this is an imperfect workaround - but might help).

Thanks, true that is a workaround for payment processor, but in that case it still shows the billing fields that appear to be required, even though they actually aren't. http://drupal.demo.civicrm.org/civicrm/event/register?reset=1&id=9

To give you some use-case history, I stumbled across this while using the Civi Discount module extension to extend 100% discounts (free) to certain events with a single event fee option only member roles. For instance, a $20 event (one and only price) is reduced to $0 by the CiviDiscount. In 3.4 and prior, Civi was capable of understanding that a the event was now effectively free, and hid any and all payment fiends, including the credit cards. In 4.2, it was not, which let to my research and filing of this issue, which is apparently has many facets.

Yash - We should minimally make sure payment_processor field formRule handles $0 total amount and is NOT REQUIRED in that case. You should also check Stuart's jQuery solution for actually hiding the billing block if total amount changes to 0 (which would be desirable).

I found several problems which need to be fixed. To recreate, start with this setup:

1. Test Processor payment process is NOT the default processor

2. Sample event id=1 (Fall Fundraiser) with Test Processor + Pay Later. Add a new $0 fee for this event

Bug 1: "Payment Processor is a required field" - form rule error even though $0 fee is selected
This happens because the payment_processor field is not checked when event/register form 1st loads and in buildQuickForm - the field is set as required, so it will throw the formRule error when radio is not checked.

====

Bug 2: If I change buildQuickForm so payment_processor is NOT required (line 452-3), then above bug is fixed, but then I can submit the form with a non-zero fee w/ checking an option in payment_processor field.

I think line 861 which is trying to handle form rule on payment_processor 'manually' should probably be

if (($fields['amount'] > 0) && empty($fields['payment_processor'])) {

... because isset will be true even when payment_processor is empty.

====

Bug 3: If I click Go Back from Confirm screen after successfully submitting a $0 fee w/o selecting a value in payment_processor (i.e. I've temporarily marked the fields as not required in buildQuickForm) - when Register form reloads, the 'Pay later' radio button is checked. Seems like somewhere in the code we are forcing payment_processor value to 0 if it's empty.

====

Bug 4: Kurund and I are getting inconsistent results with the show / hide billing blocks on $0 fee. Sometimes it works, and then I'll try again and it doesn't hide when I click $0. I'm not getting an jScript errors though

Wow Dave, good work. Impressive testing.