Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert pledge date fields to use datepicker rather than jcalendar #15170

Merged

Conversation

seamuslee001
Copy link
Contributor

@seamuslee001 seamuslee001 commented Aug 30, 2019

Overview

This PR converts the pledge form dates to use date picker rather than jcalendar and in the process renames the field pledge_payment_date on search forms to be pledge_payment_scheduled_date

Before

Jcalendar date field used

After

date picker used

Sideeffects are

  1. A bug whereby pledge based smart groups were not 'moving with the times' - saving relative date ranges - was fixed
  2. search url params now work for these fields on the pledge search screen eg

civicrm/pledge/search?reset=1&pledge_end_date_relative=this.month&force=1
civicrm/pledge/search?reset=1&pledge_start_date_relative=this.month&force=1

ping @eileenmcnaughton

@civibot
Copy link

civibot bot commented Aug 30, 2019

(Standard links)

@civibot civibot bot added the master label Aug 30, 2019
@seamuslee001 seamuslee001 force-pushed the pledge_date_picker_conversion branch 3 times, most recently from 2e9af46 to e162553 Compare August 31, 2019 06:54
$this->addSearchFieldMetadata(['Pledge' => CRM_Pledge_BAO_Query::getSearchFieldMetadata()]);
$this->addSearchFieldMetadata(['PledgePayment' => CRM_Pledge_BAO_Query::getPledgePaymentSearchFieldMetadata()]);
$this->addFormFieldsFromMetadata();
$this->setFormValues();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is a change from the approach elsewhere - if I look at CRM_Contribute_Form_Search we are relying on this being done in parent::setDefaults (which would run here too) or in preProcess - which is not very 'mature' in that the forms are not sharing a function.

I'm gonna poke around a bit more on this one

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't see how parent::setDefaults was setting the formValues where as setFormValues was calling setDefaults() and this is in the situation where we have &force=1 in the URL param

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok i think re-looking at the Contribute search this function is actually called in the postProcess function so i'll move it there

@@ -82,6 +82,12 @@ public static function select(&$query) {
$query->_tables['civicrm_pledge'] = $query->_whereTables['civicrm_pledge'] = 1;
}

if (!empty($query->_returnProperties['pledge_end_date'])) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm this shouldn't be needed - I will look & try to see why it was

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was how i fixed an issue with the api_v3_SyntaxConformanceTest

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - it's in SELECT not WHERE - which I guess is where we've been focussing cleanup

</html>
<uniqueName>pledge_end_date</uniqueName>
<uniqueTitle>Payments Ended Date</uniqueTitle>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK this confused me - I think it should be pledge end date

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eileenmcnaughton why? i thought unique title was for the search form but title would be the more standard pledge end date

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - I looks like it's unchanged in the UI so perhaps it's just me that thought pledge end made sense

@seamuslee001 seamuslee001 force-pushed the pledge_date_picker_conversion branch from e162553 to 18b01ec Compare August 31, 2019 22:36
@eileenmcnaughton
Copy link
Contributor

eileenmcnaughton commented Aug 31, 2019

@seamuslee001 so when all the metadata is being called all those _low & _high bits are obsolete (which is good because they do bad stuff). I've been trying this - but I haven't tried the payment one yet. Perhaps we should do all the xml changes first & merge?

diff --git a/CRM/Contact/BAO/Query.php b/CRM/Contact/BAO/Query.php
index 7a6b045758..37989284d0 100644
--- a/CRM/Contact/BAO/Query.php
+++ b/CRM/Contact/BAO/Query.php
@@ -1584,7 +1584,13 @@ class CRM_Contact_BAO_Query {
 
     self::filterCountryFromValuesIfStateExists($formValues);
     // We shouldn't have to whitelist fields to not hack but here we are, for now.
-    $nonLegacyDateFields = ['participant_register_date_relative', 'receive_date_relative'];
+    $nonLegacyDateFields = [
+      'participant_register_date_relative',
+      'receive_date_relative',
+      'pledge_end_date_relative',
:...skipping...
diff --git a/CRM/Contact/BAO/Query.php b/CRM/Contact/BAO/Query.php
index 7a6b045758..37989284d0 100644
--- a/CRM/Contact/BAO/Query.php
+++ b/CRM/Contact/BAO/Query.php
@@ -1584,7 +1584,13 @@ class CRM_Contact_BAO_Query {
 
     self::filterCountryFromValuesIfStateExists($formValues);
     // We shouldn't have to whitelist fields to not hack but here we are, for now.
-    $nonLegacyDateFields = ['participant_register_date_relative', 'receive_date_relative'];
+    $nonLegacyDateFields = [
+      'participant_register_date_relative',
+      'receive_date_relative',
+      'pledge_end_date_relative',
+      'pledge_start_date_relative',
+      'pledge_create_date_relative',
+    ];
     // Handle relative dates first
     foreach (array_keys($formValues) as $id) {
:...skipping...
diff --git a/CRM/Contact/BAO/Query.php b/CRM/Contact/BAO/Query.php
index 7a6b045758..37989284d0 100644
--- a/CRM/Contact/BAO/Query.php
+++ b/CRM/Contact/BAO/Query.php
@@ -1584,7 +1584,13 @@ class CRM_Contact_BAO_Query {
 
     self::filterCountryFromValuesIfStateExists($formValues);
     // We shouldn't have to whitelist fields to not hack but here we are, for now.
-    $nonLegacyDateFields = ['participant_register_date_relative', 'receive_date_relative'];
+    $nonLegacyDateFields = [
+      'participant_register_date_relative',
+      'receive_date_relative',
+      'pledge_end_date_relative',
+      'pledge_start_date_relative',
+      'pledge_create_date_relative',
+    ];
     // Handle relative dates first
     foreach (array_keys($formValues) as $id) {
       if (
diff --git a/CRM/Pledge/BAO/Query.php b/CRM/Pledge/BAO/Query.php
index 733e26abda..971993d66e 100644
--- a/CRM/Pledge/BAO/Query.php
+++ b/CRM/Pledge/BAO/Query.php
@@ -252,28 +252,6 @@ class CRM_Pledge_BAO_Query extends CRM_Core_BAO_Query {
     list($name, $op, $value, $grouping, $wildcard) = $values;
 
     switch ($name) {
-      case 'pledge_create_date_low':
-      case 'pledge_create_date_high':
-        // process to / from date
-        $query->dateQueryBuilder($values,
-          'civicrm_pledge', 'pledge_create_date', 'create_date', 'Pledge Made'
-        );
-      case 'pledge_start_date_low':
-      case 'pledge_start_date_high':
-        // process to / from date
-        $query->dateQueryBuilder($values,
-          'civicrm_pledge', 'pledge_start_date', 'start_date', 'Pledge Start Date'
-        );
-        return;
-
-      case 'pledge_end_date_low':
-      case 'pledge_end_date_high':
-        // process to / from date
-        $query->dateQueryBuilder($values,
-          'civicrm_pledge', 'pledge_end_date', 'end_date', 'Pledge End Date'
-        );
-        return;
-
       case 'pledge_payment_date_low':
       case 'pledge_payment_date_high':
         // process to / from date
diff --git a/CRM/Pledge/DAO/Pledge.php b/CRM/Pledge/DAO/Pledge.php
index baddf50a86..76d0e11dd2 100644
--- a/CRM/Pledge/DAO/Pledge.php
+++ b/CRM/Pledge/DAO/Pledge.php
@@ -6,7 +6,7 @@
  *
  * Generated from xml/schema/CRM/Pledge/Pledge.xml
  * DO NOT EDIT.  Generated by CRM_Core_CodeGen
- * (GenCodeChecksum:238d9af98168511a7e6694e3d30e533d)
+ * (GenCodeChecksum:a25cc68d8392b1d60d7179ca484b604a)
  */
 
 /**
@@ -427,6 +427,7 @@ class CRM_Pledge_DAO_Pledge extends CRM_Core_DAO {
           'description' => ts('The date the first scheduled pledge occurs.'),
           'required' => TRUE,
           'where' => 'civicrm_pledge.start_date',
+          'export' => TRUE,
           'table_name' => 'civicrm_pledge',
           'entity' => 'Pledge',
           'bao' => 'CRM_Pledge_BAO_Pledge',
@@ -498,6 +499,7 @@ class CRM_Pledge_DAO_Pledge extends CRM_Core_DAO {
           'title' => ts('Pledge End Date'),
           'description' => ts('Date this pledge finished successfully (total pledge payments equal to or greater than pledged amount).'),
           'where' => 'civicrm_pledge.end_date',
+          'export' => TRUE,
           'table_name' => 'civicrm_pledge',
           'entity' => 'Pledge',
           'bao' => 'CRM_Pledge_BAO_Pledge',
diff --git a/xml/schema/Pledge/Pledge.xml b/xml/schema/Pledge/Pledge.xml
index 28916aed10..73dfec5b20 100644
--- a/xml/schema/Pledge/Pledge.xml
+++ b/xml/schema/Pledge/Pledge.xml
@@ -196,6 +196,7 @@
     <type>datetime</type>
     <title>Pledge Start Date</title>
     <required>true</required>
+    <export>true</export>
     <comment>The date the first scheduled pledge occurs.</comment>
     <add>2.1</add>
     <html>
@@ -211,6 +212,7 @@
     <title>Pledge Made</title>
     <required>true</required>
     <import>true</import>
+    <export>true</export>
     <comment>When this pledge record was created.</comment>
     <add>2.1</add>
     <html>
@@ -248,6 +250,7 @@
     <name>end_date</name>
     <type>datetime</type>
     <title>Pledge End Date</title>
+    <export>true</export>
     <comment>Date this pledge finished successfully (total pledge payments equal to or greater than pledged amount).</comment>
     <add>2.1</add>
     <html>

@seamuslee001
Copy link
Contributor Author

possibly but the XML change will require the change to the return properties stuff tho. I guess i can see where your going with that

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 we need to stop them being converted because otherwise it saves a fixed date not a relative one & relies on magic that won't work to make relative

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton i think i got the relative dates sorted but i found that i still needed the code in the CRM/Pledge/BAO/Pledge.php for when you manually set the high and low fields

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton i have rebased this now that the xml changes have been merged

Add support for url variables

Standardise search form as per contribute form

Add in pledge payment xml change
@seamuslee001 seamuslee001 force-pushed the pledge_date_picker_conversion branch from 15a4e98 to c485300 Compare September 1, 2019 21:11
@eileenmcnaughton
Copy link
Contributor

test this please

@eileenmcnaughton
Copy link
Contributor

In my tests I found

  1. existing 'relative date range saved searches' using pledge fields were converting to hard-coded date searches on save - therefore none were 'working' & it was a moot point as to whether the conversion routine is working. Afterwards the relativeness is correctly maintained

  2. This url works http://dmaster.local/civicrm/pledge/search?reset=1&pledge_end_date_relative=this.month&force=1 to load defaults but a similar one on advanced search did not. This can be out of scope as it is non-regressive

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton do we need to update civicrm_mapping_field and civicrm_uf_field at all?

@eileenmcnaughton
Copy link
Contributor

UF Field is no - see
Screen Shot 2019-09-02 at 1 44 00 PM

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 for mapping I believe you had to update ExportTest in order to change the field names - if so I guess we could update those fields in mapping_field.

For import I wouldn't touch it - the way that code works it's using labels instead of names!

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 I also figured out what has to happen for urlsearch params to work in advanced search - this makes it work for contribute

protected function loadMetadata() {

  • we should add activity, participant, pledge there & maybe others are 'ready' - grant I think

@seamuslee001
Copy link
Contributor Author

@eileenmcnaughton in terms of the mapping_field_id i just wonder if it needs to be name spaced, maybe should leave it and see if anyone jumps?

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 yes perhaps - I think we have in practice handled updates to export mappings sometimes & not been called out when we have missed a beat - probably because mappings are generally used infrequently and there is no major ramification of it not being updated, unlike smart groups which can have complex unexpected outcomes

@seamuslee001 seamuslee001 merged commit 5a67177 into civicrm:master Sep 2, 2019
@seamuslee001 seamuslee001 deleted the pledge_date_picker_conversion branch September 2, 2019 03:44
@eileenmcnaughton
Copy link
Contributor

yay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants