The formatting of exported dataformat content is now always dependent
on whether the format supports HTML or not, so we no longer need our
custom export class for providing the same.
This option allows report creators to avoid duplicate data being
displayed in their report. It is applied only when no columns in the
report currently have aggregation methods applied.
This fixes an issue for system reports that are initialised with
parameters (such as the access report). Previously these parameters
were not preserved, when sorting/paging them via AJAX requests.
We now defer the initialisation of the report until the table
filterset has been set, ensuring all parameters are available.
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
Reports can be viewed via two methods. Non-editing users can
access them via their report listing page, and report editors
can switch between editing and preview mode while working on
their reports.
Clean up remaining string definitions.
Co-authored-by: Mikel Martín <mikel@moodle.com>
Implement module for filters editing, allowing the report
editor to define which filters are available when users
are viewing the report.
These filters allow those users viewing the report to further
limit the data being displayed (after conditions have been
applied), by selecting their own values for each filter.
Co-authored-by: Paul Holden <paulh@moodle.com>
Report conditions allow report creators to limit which data
is displayed when the report is viewed. Users viewing the
report cannot override these condition values.
Implement UI elements for editing columns of a report, taking their
definitions from the selected datasource.
Co-authored-By: David Matamoros <davidmc@moodle.com>
Co-authored-By: Mikel Martín <mikel@moodle.com>
Report columns that display the fullname of users should behave
in a consistent manner with current functionality of tables, in
regards to sorting by each individual component of a name (first
name, middle name, surname, etc).
To facilitate this, instead of a hard-coded assumption that such
columns are always named 'fullname', table classes can now define
additional columns containing a users name.
This change contains most of the output components required for
reports such as exporters, templates, AMD modules.
Also included are classes within the component table namespace which
are required for extending the dynamic table API.
Ilya Tregubov