module type extensions (not dotted notation) not supported in handlePaymentNotification

(1:12:06 PM) eileen: totten - I'm feeling like handlePaymentMethod will only wrk for dotted notation extenions
(1:12:50 PM) eileen: https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment.php#L257
(1:13:59 PM) xavier_ left the room.
(1:14:25 PM) totten: eileen: ooph, so let me speak out loud to make sure i follow
(1:15:26 PM) totten: payprocs generally need two integration points – a driver used for sending messages from civi to payproc; and an IPN (ie a driver for passing messages from payproc back to civi)
(1:15:58 PM) totten: originally (before extensions), the first would be a class (CRM_Core_Payment_Foo) and the IPN would be an adhoc .php script
(1:16:00 PM) eileen: yep
(1:16:07 PM) eileen: yep
(1:16:40 PM) totten: when extension payprocs were introduced, they provided a means for the extension to define both drivers... but the technique for IPN was different
(1:17:09 PM) eileen: well - the handle ipn was introduced later
(1:17:10 PM) totten: instead of creating a standalone script, you used civicrm/payment/ipn
(1:17:21 PM) eileen: in an ideal world the core ones would use that path too
(1:17:45 PM) totten: yup
(1:18:15 PM) totten: all payprocs – in core or in extensions – would use same code structure for inbound+outbound drivers
(1:18:43 PM) totten: can't we patch handlePaymentMethod to work with core classes (non-dotted)?
(1:18:55 PM) eileen: yeah - I'm just trying to figure it out
(1:20:03 PM) eileen: it's a bit of a wierd function
(1:20:17 PM) eileen: it does a DB look up to get all the payment-processors
(1:20:39 PM) eileen: then, for each one that matches it calls another function that does the same DB look-up
(1:21:25 PM) eileen: & appends a var to that lookup I think
(1:21:45 PM) eileen: but then it doesn't use that var
(1:22:06 PM) eileen: or most of the fields for the first db lookup because it looked it up again & the second ones are shinier
(1:23:17 PM) totten: seems likely that the DAO produced by executeQuery doesn't have as many fields as the DAO produced by CRM_Financial_BAO_PaymentProcessor::getPayment
(1:23:56 PM) totten: also, the executeQuery mixes in some joined data – which may or may not be in the second one
(1:24:48 PM) totten: for adding core support, i think the main bits are L264, L279, and L283
(1:25:21 PM) totten: ie there's a good chance that legacy payment classes (which predate handlePaymentMethod) don't have the expected $method
(1:25:59 PM) totten: but maybe that's OK – if someone tries to go to a legacy payproc via civicrm/payment/ipn, then it perhaps it should throw an error
(1:26:38 PM) eileen: totten - I think this works in my instance https://github.com/eileenmcnaughton/civicrm-core/compare/civicrm:master...patch-2?quick_pull=1
(1:26:59 PM) totten: yeah, makes sense
(1:27:13 PM) kenz [~kvirc@cpe-67-246-40-50.nycap.res.rr.com] entered the room.
(1:28:55 PM) totten: eileen: any idea about the use-case described in comments where one payproc name corresponds to both an ext-class and a core-class ?
(1:29:20 PM) eileen: hmmm
(1:30:01 PM) eileen: totten - then we should put the continue here - CRM_Core_Error::fatal("Payment processor does not implement a '$method' method");
(1:30:08 PM) eileen: instead of that line
(1:30:41 PM) totten: eileen:
(1:30:59 PM) totten: that sounds simpler than i was expecting
(1:31:14 PM) totten: makes sense