CRM-20220 fix signature fields to be longtext #9936
Conversation
eileenmcnaughton
commented
Mar 6, 2017
•
eileenmcnaughton
commented
- CRM-20220: Use text box for signature field on payment processor page
CRM/Admin/Form/PaymentProcessor.php
Outdated
| @@ -44,15 +44,8 @@ class CRM_Admin_Form_PaymentProcessor extends CRM_Admin_Form { | |||
| protected $_ppDAO; | |||
|
|
|||
| public function preProcess() { | |||
| if (!CRM_Core_Permission::check('administer payment processors')) { | |||
There was a problem hiding this comment.
moved this to the xml definition of the form
| parent::preProcess(); | ||
|
|
||
| CRM_Utils_System::setTitle(ts('Settings - Payment Processor')); |
| @@ -77,10 +70,6 @@ public function preProcess() { | |||
| $this->_ppDAO = new CRM_Financial_DAO_PaymentProcessorType(); | |||
| $this->_ppDAO->id = $this->_ppType; | |||
|
|
|||
| if (!$this->_ppDAO->find(TRUE)) { | |||
There was a problem hiding this comment.
this is checking for an impossible condition
eileenmcnaughton
force-pushed
the
sig
branch
3 times, most recently
from
9b61218
to
a0315a3
Compare
CRM/Core/Form.php
Outdated
| @@ -1375,7 +1379,7 @@ public function addSelect($name, $props = array(), $required = FALSE) { | |||
| * @throws \Exception | |||
| * @return HTML_QuickForm_Element | |||
| */ | |||
| public function addField($name, $props = array(), $required = FALSE, $legacyDate = TRUE) { | |||
| public function addField($name, $props = array(), $required = FALSE, $fieldSpec = array(), $legacyDate = TRUE) { | |||
There was a problem hiding this comment.
@colemanw what is your opinion on this. It feels like the easiest way to make the fields on the payment processor form metadata driven. However, some of the fields are pseudofields so I figured maybe we could change the scope here to allow them to be passed in
There was a problem hiding this comment.
I don't think we ought to use this function with pseudofields.
| @@ -45,10 +45,10 @@ class CRM_Contact_Form_Edit_Demographics { | |||
| public static function buildQuickForm(&$form) { | |||
| $form->addField('gender_id', array('entity' => 'contact', 'type' => 'Radio', 'allowClear' => TRUE)); | |||
|
|
|||
| $form->addField('birth_date', array('entity' => 'contact'), FALSE, FALSE); | |||
| $form->addField('birth_date', array('entity' => 'contact'), FALSE, array(), FALSE); | |||
There was a problem hiding this comment.
The legacyDateParam is v recent & transitional so I know these are the only fields using it
|
@eileenmcnaughton unfortunately this is stale |
|
@colemanw I fixed the staleness. Re adding the test fields: here's the thing, the fields create a second row in the payment processor table, but they arguably are 'real fields' because the way it works is you update them in practice as if they were one thing (I might almost wish they were one row in the table!) I did think about adding them to getfields so the api understood them as part of the set of fields to be added, if we were thinking about putting them in one row, one day that would be a good step towards that. The difficulty would be on the off chance someone really did want to use the api to alter just the test fields, hence I thought maybe I should do trickery at the form layer. I guess I can go back to 'add' if there is no metadata way to do this |
|
I agree with |
|
@colemanw ok, I've switched the test fields back... |
|
test this please |
CRM/Admin/Form/PaymentProcessor.php
Outdated
| * @return string | ||
| * The entity being edited. | ||
| * | ||
| * @throws Exception |
|
@colemanw this has passed tests with your update, do you think it's good to merge now? |
CRM-20220 fix signature fields to be longtext
