This bug was caused when the chart encountered data outside of its
visible range (i.e., the upper bound of the array size). A test was
added that inserts some data from 2 years and 16 months in the past.
The test failed on the old version, throwing exactly the error in bug
report #1442.
The fix is to check whether or not the value is within the array range
before sending the "+=" operator. With this change, the test passes.
Also removing the python-esque combination methods to set multiple
disparate variables from a single method by refactoring that to a
simpler method.
Reducing the complexity of computing running averages.
Note: It is not clear to me why the actions_done_lastyears_data
action is entirely unscoped on date. That seems to be the expected
behavior, so I left it alone.
This removes some intermediate steps that were ultimately not necessary
to the math. It also consolidates some of the methods for counting events
so that fewer intermediate values are necessary.
To that end, a new scope is added to the ToDo model for events that are
*either* created_at or completed_at after a certain date. This scope
allows the StatsController to pull out the largest possible responsive
set of values, and then filter just the particular slices that it needs
for various steps in the calculation.
Also removing some instance variables that were never invoked in the
views. This sets up a future refactoring of the method of comptuting
rolling averages, which differs between the two types of "last year"
views being refactored.
Pull logic into the controller from the view. There were only a couple
of tiny differences between the running actions and the total actions
view, so I added a couple of instance variables and then called the same
template twice.
This may be a bit extreme.
It's modeled after the ideal "rails way".
In the controller, we now know the name of a single resource. It
doesn't happen to be backed by a database table, but it does know all
about the task of collecting stats, leaving the controller concerned
with just munging params and rendering stuff.
I called the resource `IndexPage`, to avoid the temptation of trying to
reuse it, which can get pretty messy.
Later, if a better abstraction appears, it should be fairly painless to
alter.
If you have fewer than 10 projects, then empty running projects were
linked to with the path `/projects/-1`.
Copy/pasted the list strategy from the other project sections in the
same partial so the duplication becomes explicit.
The tag cloud minimum used to start at 0, then repeatedly compared to
the lowest count and chose the smallest, which is bound to be zero in
every case.
Discussed
[here](8c26ea7cb5 (commitcomment-2719199)).
The current user isn't necessarily current when it is in the model
layer.
The exposed attributes on the tag cloud no longer need to contain type
information.
