-
-
Notifications
You must be signed in to change notification settings - Fork 825
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
Conversation
(Standard links)
|
@@ -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']; |
There was a problem hiding this comment.
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': |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because of field renaming
CRM/Core/Form.php
Outdated
@@ -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 |
There was a problem hiding this comment.
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)) { |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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
e5da5fb
to
859ebc3
Compare
@eileenmcnaughton do we need to do any smart group conversion here? |
@seamuslee001 yes - see outstanding items above - we actually need a routine to RENAME the key first & then convert it - or vice versa |
CRM/Core/Form/Search.php
Outdated
@@ -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'); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; | ||
} | ||
|
There was a problem hiding this comment.
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.
859ebc3
to
a1c5b0f
Compare
@seamuslee001 I added the upgrade routine |
efd2dc5
to
ecda3b1
Compare
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 |
CRM/Contact/Form/Search/Basic.php
Outdated
@@ -200,7 +200,7 @@ public function postProcess() { | |||
* | |||
* @return array|bool | |||
*/ | |||
public static function formRule($fields) { | |||
public static function formRule($fields, $files, $form) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eileenmcnaughton extra space here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ug- fixed
5d0ec9f
to
3466488
Compare
@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
(CiviCRM Review Template WORD-1.2)
|
3466488
to
8e80025
Compare
Merging as per my review and the tag |
thanks @seamuslee001 hopefully this will make future conversions easier |
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.
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.
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
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.
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
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
-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)