CRM-20591 Disabling a payment processor via UI (other than Payment_PayPalImpl) will break live mode

There's recent work in this area on CRM-19900, but IDK if this bug existed before then.

Matthew Wire Eileen McNaughton pinging you since you perhaps tested this when looking at those changes and recall what behaviour was going on before/after?

I should note that I've confirmed this as far as "leaves the DB data in a weird and broken looking state", but the actual breakage of payments is not something I've confirmed yet (I believe Peter Davis has already).

Does the same thing happen when you do it through the detail screen? ie. civicrm/admin/paymentProcessor?action=update&id=XX&reset=1, tick/untick the is active checkbox and save.

The method of updating the payment processor to test mode seems to be an AJAX call which does payment_processor.create with only ID and is_active.

curl 'http://civicrm.dev/civicrm/ajax/rest' \
-XPOST \
-H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' \
-H 'Referer: http://civicrm.dev/civicrm/admin/paymentProcessor?reset=1' \
-H 'Accept: application/json, text/javascript, */*; q=0.01' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30' \
-H 'Origin: http://civicrm.dev' \
-H 'X-Requested-With: XMLHttpRequest' \
--data 'entity=payment_processor&action=create&json=%7B%22id%22%3A%223%22%2C%22is_active%22%3A0%7D'

It seems like the same behaviour can be repeated with the API call directly.

cv api payment_processor.create id=3 is_active=0

So maybe the API create method slaps in some defaults here, rather than using the existing data for that entity?

https://gist.github.com/xurizaemon/afad63b708cc12b02c95ce50380742a2 - results via CLI

Matthew Wire, disabling via the "Edit" screen for a payment processor does NOT trigger this behaviour.

ug - must be some default kicking in - yuck

I'm happy to contribute a test for this, because it's going to boil down to

cv api payment_processor.create class_name=Foo
(get the id)
cv api payment_processor.create is_active=0 id=X
cv api payment_processor.get id=X
(check the class name)

This feels like the sort of test which might be generalised across all entities, if we know the following:

• A list of entities (I believe we do)
• A list of (valid) entity properties (I believe we do)
• Some random things to create (this might be the tricky bit)

Does a similar test already exist?

Seems it is not a regression as I can replicate this on 4.6 too and the affected code has not been changed from a long time(shows imported from svn on git blame). Will submit a PR soon.

PR has been merged.