Amendments to the column class allow reports/entities to specify these
options for column instances, which are then passed to the aggregation
type when it is applied.
This allows each class to define the type of data that they return,
regardless of the type of column to which they are applied. This is the
pre-cursor to work on graphing and filtering of aggregated data.
E.g. a text field that is aggregated with "count" is returning numeric
data rather than text.
This change introduces updates to the existing aggregation API, to
allow types to define whether to group by fields of a column to which
the aggregation is applied.
The new date aggregation utilises this, to allow for creation of time
series reports, e.g. report data grouped by dates.
Co-authored-by: Daniel Neis Araujo <danielneis@gmail.com>
When concatenating column fields in order to perform aggregation on
them (e.g. group concatenation), we need to preserve all null values
in the data passed to each column callback.
Co-authored-by: Carlos Castillo <carlos.castillo@moodle.com>
When using the "Count distinct" aggregation type on a column that
selects multiple fields, we should account for each of them in the
returned SQL.
Move helper method to facilitate this to the base aggregation class
so it can be re-used between all types.
The group concatenation types now consistently sort the returned values
and support aggregating columns containing multiple fields and those
with defined callbacks.
Refinements to how columns can be defined in relation to available
aggregation methods:
* Disable aggregation types;
* Set column GROUP BY during aggregation;
* Defer column sorting to that of the aggregation method
Paul Holden