Answers.Body: <p>This isn't a full answer, but we (Karin actually) discovered that by removing the redis caching configuration from the civicrm settings file, the problem went away.</p>
  
  <p>This is a bit weird, since the problem I was looking at was the static code cache, but it sort of makes sense if the api call that pulls in the payment object could potentially be reading from the more permanent (usually mysql table) cache.</p>
  
  <p>So, my best guess to this issue is that there is some code somewhere that is accessing the CiviCRM cache without using or knowing about the use of Redis.</p>
  
  <p>On it's own, this just means we can't use the Redis cache for CiviCRM, but it suggests that there might be a bigger problem hiding in here.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-24T19:03:41.093Z
Answers.LastActivityDate: 2019-05-24T19:03:41.093Z
Answers.UserDisplayName: Alan Dixon
Body: <p>Using CiviCRM 5.7.6 w/ Drupal, I'm getting an issue with my backoffice contribution forms. Specifically, even though the configuration says not to require CVV, and the form itself does not have a (*) to indicate it's required, I'm still getting an error if I submit the form without a CVV, and the error tells me that I require the CVV.</p>
  
  <p>When I look at the code, the key seems to this piece of code, around line 278 in CRM/Core/Payment/Form.php:</p>
  
  <pre><code>  public static function validatePaymentInstrument($payment_processor_id, $values, &amp;$errors, $billing_profile_id) {
  $payment = Civi\Payment\System::singleton()-&gt;getById($payment_processor_id);
  $payment-&gt;setBillingProfile($billing_profile_id);
  $payment-&gt;validatePaymentInstrument($values, $errors);
  </code></pre>
  
  <p>}</p>
  
  <p>Specifically, the validatePaymentInstrument call of the payment object triggers the error because the payment object itself doesn't have the isBackOffice property set. It's not clear to me why it should have that isBackOffice property set unless that object had been created earlier in the code flow and the backoffice property set there.</p>
  
  <p>It also seems to me that this form is the backoffice form, so we could put in a setBackOffice call just before the validate call, but I'm curious why this code seems to have worked in the past.</p>
  
  <p>I'll note also that the error is relatively recent, and it's not clear to me whether it might be code version and/or php version dependent.</p>
  
  <p><a href="https://i.sstatic.net/7TOd5.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/7TOd5.png" alt="enter image description here"></a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-23T00:56:34.130Z
Comments.Text: There were JIRA issues way back about this but expect you have found them eg https://issues.civicrm.org/jira/browse/CRM-20166, https://issues.civicrm.org/jira/browse/CRM-10366, https://github.com/civicrm/civicrm-core/pull/11205
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-23T15:51:57.047Z
Comments.Text: Yes, it's not clear to me if those are related or not - the code included in those issues seems correct and not a cause of what I'm experiencing, which I suspect is a bit subtle.
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-23T16:41:17.037Z
Comments.Text: We have exactly the same issue, and I'd got pretty much exactly as far as you in debugging it. It kicked in for us sometime in early May, and doesn't seem to be related to an upgrade or a PHP version. We're on WordPress and Civi 5.11. I'll report back when I have a change to dig into it some more.
Comments.UserDisplayName: Andrew West
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-05-23T19:06:30.560Z
Comments.Text: Thanks Andrew, that makes me happy! FWIW, I was still able to reproduce the bug after switching my php back to 7.0.
Comments.UserDisplayName: Alan Dixon
Tags: <civicontribute><payment>
Title: CVV is being required in backoffice, even when it shouldn't be
ThreadText: # CVV is being required in backoffice, even when it shouldn't be
  
  (Asked by: username_0 on 2019-05-22)
  
  Using CiviCRM 5.7.6 w/ Drupal, I'm getting an issue with my backoffice contribution forms. Specifically, even though the configuration says not to require CVV, and the form itself does not have a (*) to indicate it's required, I'm still getting an error if I submit the form without a CVV, and the error tells me that I require the CVV.
  When I look at the code, the key seems to this piece of code, around line 278 in CRM/Core/Payment/Form.php:
    public static function validatePaymentInstrument($payment_processor_id, $values, &$errors, $billing_profile_id) {
  $payment = Civi\Payment\System::singleton()->getById($payment_processor_id);
  $payment->setBillingProfile($billing_profile_id);
  $payment->validatePaymentInstrument($values, $errors);
  
  }
  Specifically, the validatePaymentInstrument call of the payment object triggers the error because the payment object itself doesn't have the isBackOffice property set. It's not clear to me why it should have that isBackOffice property set unless that object had been created earlier in the code flow and the backoffice property set there.
  It also seems to me that this form is the backoffice form, so we could put in a setBackOffice call just before the validate call, but I'm curious why this code seems to have worked in the past.
  I'll note also that the error is relatively recent, and it's not clear to me whether it might be code version and/or php version dependent.
  
  **Tags:** civicontribute, payment
  
  > **Comments:**
  > **username_1**: There were JIRA issues way back about this but expect you have found them eg https://issues.civicrm.org/jira/browse/CRM-20166, https://issues.civicrm.org/jira/browse/CRM-10366, https://github.com/civicrm/civicrm-core/pull/11205  
  > **username_0**: Yes, it's not clear to me if those are related or not - the code included in those issues seems correct and not a cause of what I'm experiencing, which I suspect is a bit subtle.  
  > **username_2**: We have exactly the same issue, and I'd got pretty much exactly as far as you in debugging it. It kicked in for us sometime in early May, and doesn't seem to be related to an upgrade or a PHP version. We're on WordPress and Civi 5.11. I'll report back when I have a change to dig into it some more.  
  > **username_0**: Thanks Andrew, that makes me happy! FWIW, I was still able to reproduce the bug after switching my php back to 7.0.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2019-05-24. Score: 6 | Accepted answer
  
  This isn't a full answer, but we (Karin actually) discovered that by removing the redis caching configuration from the civicrm settings file, the problem went away.
  
  This is a bit weird, since the problem I was looking at was the static code cache, but it sort of makes sense if the api call that pulls in the payment object could potentially be reading from the more permanent (usually mysql table) cache.
  
  So, my best guess to this issue is that there is some code somewhere that is accessing the CiviCRM cache without using or knowing about the use of Redis.
  
  On it's own, this just means we can't use the Redis cache for CiviCRM, but it suggests that there might be a bigger problem hiding in here.
  
  
  ---
  
  