Details
-
Type:
Patch
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.2.6, 4.2.15
-
Fix Version/s: 4.3.0
-
Component/s: CiviReport
-
Labels:None
-
Documentation Required?:None
-
Funding Source:Needs Funding
Description
To test with built-in reports, apply the attached file "time_filter_testing.patch"
Issue: Time was not displayed in the report "stats" summary
- Enter a date and time range in the "Contribution Details" report.
- Preview Report
- The filter summary will only display "Receive Date: Between July 1st, 2009 and July 1st, 2009" or whatever your dates were. Time is missing.
Attachments
Activity
4.3 / trunk includes some more fixes/improvements w.r.t datetime. The patch / issue doesn't cleanly apply, plus doesn't make it clear on how to test the fix with existing reports.
Report requires a new operator type if you also want to include a time filter in addition to just date. Would be great if you could support your fix with an example of existing or new report (especially filter part).
Deepak, thank you for taking a look at this patch.
The first two issues I was complaining about were indeed fixed in trunk, so I emended my patch to fix the one remaining issue (and also removed the redundant default times). I went ahead and committed this.
Looks good.
Thanks for the patch.
Would be great to also have a new operator type for date time fields, so that it could be controlled at field level. Should be trivial. Ping me on irc if interested in doing it.
This has regressed in 4.2.15
Sorry, I see that the issue was never fixed in 4.2... I've pushed a PR which should fix on the LTS branch.
https://github.com/CiviCRM42/civicrm42-core/pull/59
Part of this patch is suspect, because I ported from 4.1.1 – I removed these lines from dateClause, since T_DATE is the only filter type which has date range behavior, but it was stripping the time component from the WHERE clause.
> $from = ($type == CRM_Utils_Type::T_DATE)?substr($from,0,8 ):$from;
> $to = ($type == CRM_Utils_Type::T_DATE)?substr($to, 0, 8 ):$to;
This was also causing a single-day search to fail because the time range, which should have been 000000-235959, was instead 000000-000000