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 activity_date_time field to datepicker and add support for url input #13746

Merged
merged 6 commits into from
Mar 5, 2019

Conversation

eileenmcnaughton
Copy link
Contributor

@eileenmcnaughton eileenmcnaughton commented Mar 2, 2019

Overview

Convert activity_date_time field on activity search page to use datepicker, add support for parameters to this in the url

Before

Deprecated jcalendar

After

Preferred datepicker & metadata approaches in use. Generic url support added with tight validation

screenshot 2019-03-02 19 05 33

Technical Details

This converts the form to being a metadata defined field & a date-picker field as well
as adding standardised url support for input.

The input format is
activity_date_time_high=20100101

I stripped out the complex and probably broken based on feedback & not used in core
existing hard-coded url support.

Note that there are some outstanding items

  1. I updated the check to ensure the high date is greater than the low date
    -but it DOES display more than once if it fails - I think we could hone that later

Comments

@monishdeb @colemanw you both seem to be working on making search form changes that can be solved by adopting a generic approach - here is how I see it working for the activity date time field. We should be able to update similar fields like 'contribution receive date', membership start date , birth date etc with less code change as the Core_Form & Form_Search changes are to support time in datepicker ranges & url support for date fields (respectively)

@civibot
Copy link

civibot bot commented Mar 2, 2019

(Standard links)

@civibot civibot bot added the master label Mar 2, 2019
@@ -440,7 +442,7 @@ public static function from($name, $mode, $side) {
* rather than a static function.
*/
public static function getSearchFieldMetadata() {
$fields = ['activity_type_id'];
$fields = ['activity_type_id', 'activity_date_time'];
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 is the key change - adding the field to this array means it can be removed from other places

@@ -288,8 +288,10 @@ public static function whereClauseSingle(&$values, &$query) {
case 'activity_date':
case 'activity_date_low':
case 'activity_date_high':
case 'activity_date_time_low':
Copy link
Contributor Author

Choose a reason for hiding this comment

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

because I renamed the field to be more std

*
* @return bool|array
*/
public static function formRule($fields, $files, $form) {
Copy link
Contributor Author

@eileenmcnaughton eileenmcnaughton Mar 2, 2019

Choose a reason for hiding this comment

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

We can re-add something generic for these if we think it's important (I'm inclined to punt a bit on this since I think it's not currently consistently done for date fields in search which makes is seem not that important)

@@ -1899,6 +1899,8 @@ public function whereClauseSingle(&$values, $apiEntity = NULL) {
case 'activity_date':
case 'activity_date_low':
case 'activity_date_high':
case 'activity_date_time_low':
Copy link
Contributor Author

Choose a reason for hiding this comment

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

because of field renaming

@@ -1298,8 +1298,10 @@ public function addDateRange($name, $from = '_from', $to = '_to', $label = 'From
* @param bool $required
* @param string $fromLabel
* @param string $toLabel
* @param bool $isDateTime
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Add time support to addDatePickerRange fn

if ($fieldSpec['type'] === CRM_Utils_Type::T_DATE) {
// Assuming time is false for now as we are not checking for date-time fields as yet.
$this->addDatePickerRange($fieldName, $fieldSpec['title'], FALSE);
if ($fieldSpec['type'] === CRM_Utils_Type::T_DATE || $fieldSpec['type'] === (CRM_Utils_Type::T_DATE + CRM_Utils_Type::T_TIME)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Add time support

@@ -184,6 +183,10 @@ protected function getValidationTypeForField($entity, $fieldName) {
case CRM_Utils_Type::T_INT:
return 'CommaSeparatedIntegers';

case CRM_Utils_Type::T_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.

Add validation support - we validate these fields as 20190212 or 20190212123000

@eileenmcnaughton eileenmcnaughton force-pushed the activity_search branch 2 times, most recently from e5da5fb to 859ebc3 Compare March 2, 2019 06:16
@seamuslee001
Copy link
Contributor

@eileenmcnaughton do we need to do any smart group conversion here?

@eileenmcnaughton
Copy link
Contributor Author

@seamuslee001 yes - see outstanding items above - we actually need a routine to RENAME the key first & then convert it - or vice versa

@@ -204,6 +207,15 @@ protected function getEntityDefaults($entity) {
if ($value !== FALSE) {
$defaults[$fieldSpec['name']] = $value;
}
if ($fieldSpec['type'] === CRM_Utils_Type::T_DATE || ($fieldSpec['type'] === CRM_Utils_Type::T_DATE + CRM_Utils_Type::T_TIME)) {
$low = CRM_Utils_Request::retrieveValue($fieldSpec['name'] . '_low', 'Timestampe', FALSE, NULL, 'GET');
Copy link
Member

Choose a reason for hiding this comment

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

@eileenmcnaughton I think we should also include '_from'/'_to' names?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since we'll be converting the fields one by one hopefully we can just standardise them in the process.

$this->_formValues['activity_date_high'] = $dateHigh;
$this->_defaults['activity_date_high'] = $dateHigh;
}

Copy link
Member

Choose a reason for hiding this comment

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

on grep this datelow/high is only used in Activity search form as url arguments, so its safe to remove.

@eileenmcnaughton
Copy link
Contributor Author

@seamuslee001 I added the upgrade routine

@eileenmcnaughton eileenmcnaughton force-pushed the activity_search branch 3 times, most recently from efd2dc5 to ecda3b1 Compare March 4, 2019 00:14
@eileenmcnaughton
Copy link
Contributor Author

I've made some updates to improve the conversion routine & also put in a form rule - the form rule runs twice but as an annoyance this is a real edge case (ie. it might annoy you to see the message twice if you misenter the date but not that many people would hit it & even less would care)

@colemanw I found that I needed to do some more conversion work on relative dates for the activity field - I don't know how well relative dates convert on the age as of field - my guess is they don't work & maybe even shouldn;t

It would be good to get someone else try to hammer this a bit & see if they can find ways that it breaks - it would be good to get it in the rc then we could add some more date fields to the next release & we would have the twin goals of getting rid of jcalender & adding url support for datefields in hand. I think we could also fix the open bug on custom fields with relative dates in the process

@@ -200,7 +200,7 @@ public function postProcess() {
*
* @return array|bool
*/
public static function formRule($fields) {
public static function formRule($fields, $files, $form) {
Copy link
Member

Choose a reason for hiding this comment

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

@eileenmcnaughton extra space here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ug- fixed

@eileenmcnaughton
Copy link
Contributor Author

@monishdeb @colemanw @seamuslee001 does anyone have time to check this before the rc is cut - otherwise I'll need to change the upgrade script

…l input

This converts the form to being a metadata defined field & a date-picker field as well
as adding standardised url support for input.

The input format is
activity_date_time_high=20100101

I stripped out the complex and probably broken based on feedback  & not used in core
existing hard-coded url support.

Note that there are some outstanding items
1) the upgrade script item needs to be added - this includes dealing with renaming of the field
since I made it more consistent
2) I stripped out the check to ensure the high date is greater than the low date
- if we still want this we should re-add as a generic thing. My guess is it's a bit optional
Old format doesn't seem to have it
@seamuslee001
Copy link
Contributor

(CiviCRM Review Template WORD-1.2)

  • General standards
    • (r-explain) Pass
    • (r-user) Pass
    • (r-doc) Pass
    • (r-run) Pass i created 2 separate smart groups 1 with a relative date and one an exact date and confirmed that after running the upgrade they were both correctly converted and loaded correctly. I also confirmed the form rule works as expected.
  • Developer standards

@seamuslee001
Copy link
Contributor

Merging as per my review and the tag

@seamuslee001 seamuslee001 merged commit f043815 into civicrm:master Mar 5, 2019
@eileenmcnaughton eileenmcnaughton deleted the activity_search branch March 5, 2019 22:41
@eileenmcnaughton
Copy link
Contributor Author

thanks @seamuslee001 hopefully this will make future conversions easier

demeritcowboy added a commit to demeritcowboy/civicrm-core that referenced this pull request Apr 8, 2019
civicrm#13746 adds a formRule function to CRM_Core_Form_Search which is the parent of CRM_Case_Form_Search. It already has a formRule function but the signatures don't match.
demeritcowboy added a commit to demeritcowboy/civicrm-core that referenced this pull request Apr 8, 2019
civicrm#13746 adds a formRule function to CRM_Core_Form_Search which is the parent of CRM_Case_Form_Search. It already has a formRule function but the signatures don't match.
demeritcowboy added a commit to demeritcowboy/civicrm-core that referenced this pull request Apr 8, 2019
civicrm#13746 adds a formRule function to CRM_Core_Form_Search which is the parent of CRM_Case_Form_Search. It already has a formRule function but the signatures don't match.

argh
demeritcowboy added a commit to demeritcowboy/civicrm-core that referenced this pull request Apr 8, 2019
civicrm#13746 adds a formRule function to CRM_Core_Form_Search which is the parent of CRM_Case_Form_Search. It already has a formRule function but the signatures don't match.
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.

3 participants