Merge pull request #13193 from civicrm/5.8
[civicrm-core.git] / CRM / Core / Payment / Dummy.php
index 7a40da5f7921eec81e921b864fb669ff1f245202..1d68efe868121367667d198e7dc61121f02b5830 100644 (file)
@@ -127,7 +127,10 @@ class CRM_Core_Payment_Dummy extends CRM_Core_Payment {
   }
 
   /**
-   * Are back office payments supported - e.g paypal standard won't permit you to enter a credit card associated with someone else's login
+   * Are back office payments supported.
+   *
+   * E.g paypal standard won't permit you to enter a credit card associated with someone else's login.
+   *
    * @return bool
    */
   protected function supportsLiveMode() {
@@ -166,4 +169,33 @@ class CRM_Core_Payment_Dummy extends CRM_Core_Payment {
     return NULL;
   }
 
+  /**
+   * Get an array of the fields that can be edited on the recurring contribution.
+   *
+   * Some payment processors support editing the amount and other scheduling details of recurring payments, especially
+   * those which use tokens. Others are fixed. This function allows the processor to return an array of the fields that
+   * can be updated from the contribution recur edit screen.
+   *
+   * The fields are likely to be a subset of these
+   *  - 'amount',
+   *  - 'installments',
+   *  - 'frequency_interval',
+   *  - 'frequency_unit',
+   *  - 'cycle_day',
+   *  - 'next_sched_contribution_date',
+   *  - 'end_date',
+   *  - 'failure_retry_day',
+   *
+   * The form does not restrict which fields from the contribution_recur table can be added (although if the html_type
+   * metadata is not defined in the xml for the field it will cause an error.
+   *
+   * Open question - would it make sense to return membership_id in this - which is sometimes editable and is on that
+   * form (UpdateSubscription).
+   *
+   * @return array
+   */
+  public function getEditableRecurringScheduleFields() {
+    return array('amount', 'next_sched_contribution_date');
+  }
+
 }