X-Git-Url: https://vcs.fsf.org/?a=blobdiff_plain;f=CRM%2FCore%2FPayment%2FDummy.php;h=d52efbb4108c5b5958e2175ab04759e1ee4d5fa0;hb=70115ad4db093fb4b01a8f1ecc8ccf541a869d63;hp=b48e6bf96563060bc953be91061d038f4ff1ec9a;hpb=91780c73737d21fa0619f233b543910e248ea7e7;p=civicrm-core.git diff --git a/CRM/Core/Payment/Dummy.php b/CRM/Core/Payment/Dummy.php index b48e6bf965..d52efbb410 100644 --- a/CRM/Core/Payment/Dummy.php +++ b/CRM/Core/Payment/Dummy.php @@ -24,6 +24,23 @@ class CRM_Core_Payment_Dummy extends CRM_Core_Payment { protected $_mode; protected $_doDirectPaymentResult = []; + /** + * This support variable is used to allow the capabilities supported by the Dummy processor to be set from unit tests + * so that we don't need to create a lot of new processors to test combinations of features. + * Initially these capabilities are set to TRUE, however they can be altered by calling the setSupports function directly from outside the class. + * @var bool[] + */ + protected $supports = [ + 'MultipleConcurrentPayments' => TRUE, + 'EditRecurringContribution' => TRUE, + 'CancelRecurringNotifyOptional' => TRUE, + 'BackOffice' => TRUE, + 'NoEmailProvided' => TRUE, + 'CancelRecurring' => TRUE, + 'FutureRecurStartDate' => TRUE, + 'Refund' => TRUE, + ]; + /** * Set result from do Direct Payment for test purposes. * @@ -53,6 +70,111 @@ class CRM_Core_Payment_Dummy extends CRM_Core_Payment { $this->_paymentProcessor = $paymentProcessor; } + /** + * Does this payment processor support refund? + * + * @return bool + */ + public function supportsRefund() { + return $this->supports['Refund']; + } + + /** + * Should the first payment date be configurable when setting up back office recurring payments. + * + * We set this to false for historical consistency but in fact most new processors use tokens for recurring and can support this + * + * @return bool + */ + public function supportsFutureRecurStartDate() { + return $this->supports['FutureRecurStartDate']; + } + + /** + * Can more than one transaction be processed at once? + * + * In general processors that process payment by server to server communication support this while others do not. + * + * In future we are likely to hit an issue where this depends on whether a token already exists. + * + * @return bool + */ + protected function supportsMultipleConcurrentPayments() { + return $this->supports['MultipleConcurrentPayments']; + } + + /** + * Checks if back-office recurring edit is allowed + * + * @return bool + */ + public function supportsEditRecurringContribution() { + return $this->supports['EditRecurringContribution']; + } + + /** + * Are back office payments supported. + * + * e.g paypal standard won't permit you to enter a credit card associated + * with someone else's login. + * The intention is to support off-site (other than paypal) & direct debit but that is not all working yet so to + * reach a 'stable' point we disable. + * + * @return bool + */ + protected function supportsBackOffice() { + return $this->supports['BackOffice']; + } + + /** + * Does the processor work without an email address? + * + * The historic assumption is that all processors require an email address. This capability + * allows a processor to state it does not need to be provided with an email address. + * NB: when this was added (Feb 2020), the Manual processor class overrides this but + * the only use of the capability is in the webform_civicrm module. It is not currently + * used in core but may be in future. + * + * @return bool + */ + protected function supportsNoEmailProvided() { + return $this->supports['NoEmailProvided']; + } + + /** + * Does this processor support cancelling recurring contributions through code. + * + * If the processor returns true it must be possible to take action from within CiviCRM + * that will result in no further payments being processed. In the case of token processors (e.g + * IATS, eWay) updating the contribution_recur table is probably sufficient. + * + * @return bool + */ + protected function supportsCancelRecurring() { + return $this->supports['CancelRecurring']; + } + + /** + * Does the processor support the user having a choice as to whether to cancel the recurring with the processor? + * + * If this returns TRUE then there will be an option to send a cancellation request in the cancellation form. + * + * This would normally be false for processors where CiviCRM maintains the schedule. + * + * @return bool + */ + protected function supportsCancelRecurringNotifyOptional() { + return $this->supports['CancelRecurringNotifyOptional']; + } + + /** + * Set the return value of support functions. By default it is TRUE + * + */ + public function setSupports(array $support) { + $this->supports = array_merge($this->supports, $support); + } + /** * @param array|PropertyBag $params * @@ -129,24 +251,6 @@ class CRM_Core_Payment_Dummy extends CRM_Core_Payment { return $result; } - /** - * Does this payment processor support refund? - * - * @return bool - */ - public function supportsRefund() { - return TRUE; - } - - /** - * Supports altering future start dates. - * - * @return bool - */ - public function supportsFutureRecurStartDate() { - return TRUE; - } - /** * Submit a refund payment * @@ -196,19 +300,6 @@ class CRM_Core_Payment_Dummy extends CRM_Core_Payment { return ['amount', 'next_sched_contribution_date']; } - /** - * Does this processor support cancelling recurring contributions through code. - * - * If the processor returns true it must be possible to take action from within CiviCRM - * that will result in no further payments being processed. In the case of token processors (e.g - * IATS, eWay) updating the contribution_recur table is probably sufficient. - * - * @return bool - */ - protected function supportsCancelRecurring() { - return TRUE; - } - /** * Cancel a recurring subscription. *