Genericise 'ending' date filter and add tests
authoreileen <emcnaughton@wikimedia.org>
Fri, 17 Aug 2018 02:48:35 +0000 (14:48 +1200)
committereileen <emcnaughton@wikimedia.org>
Fri, 7 Sep 2018 22:11:19 +0000 (10:11 +1200)
commitad336d61afe346478f78fc232faa9f9c33bdee93
tree0a5dd1bd4de534a4f452328fc7538e116b5afb5f
parentbdf6f906cbf154f72d078d3fa490510f2a68aea4
Genericise 'ending' date filter and add tests

Currently we have hard coded variants of 'ending_2.year' for 'Last 2 years including today' and
for month, week and quarter we support last month ending today etc. This adds tests
for the units already existing and also adds support (but no UI entries) for
ending_n.month
ending_n.week
ending_n.year
ending_n.day
ending_n.quarter

There is a complexity in that the current month entries are
ending_2.month = 'Last 60 days ending today'
ending.quarter = 'Last 90 days ending today'

I think it was done this way primarily to get the language right but as the period gets longer
(my interest is in supporting 18 months) the mismatch between 30 days & a month becomes more &
more of an issue.

I haven't focussed on any code rationalisation as I wanted to keep this to
additional code not changes to current & discuss / agree if this approach (ie. for the 'n'
entries we are respectful of actual month lengths & we leave it to future option value
enterers to worry about the wording.

I actually feel a pretty good case could be made for replacing the default
entries so instead of

ending_2.month = Last 60 days including today

we have

ending_60.day = Last 60 days including today

(This makes that change on new installs only)
CRM/Utils/Date.php
tests/phpunit/CRM/Utils/DateTest.php
xml/templates/civicrm_data.tpl