The component the audience belongs to is used by the cards exporter
for rendering the editing interface. Avoid duplication in determining
this value by defining appropriate method in the base class.
During request lifecycle ensure that column, filter and condition
persistents are only loaded a single time to prevent additional
database reads.
Provide invalidation method, used by the report helpers, to ensure
that the persistents are re-loaded appropriately.
Co-authored-by: Marina Glancy <marina@moodle.com>
The custom report exporter should define its own editable element
properties (conditions, filters, etc) as optional, rather than each
of those element exporters defining their properties as optional.
When resetting report filters, we need to include the original report
parameters in the external method call to ensure all those that are
required during validation are present (e.g. when determining if user
can view the current system report).
When instantiating classes that extend `inplace_editable` we can
improve performance by passing persistent instances we already have,
rather than re-requesting them.
Add test coverage to relevant classes.
Given that custom reports can now have defined pagesize properties, we
need to preserve that value in the table filterset so that it's always
available after AJAX requests.
Aggregation types can disable column sorting, e.g. both the current
group concatenation types. If such a type is selected for a column
we should update the report sorting options, ensuring that only those
columns that can be sorted are available for selection.
We should gracefully handle invalid element models that refer to
columns, filters, conditions that are no longer defined within the
report/entity they are linked to.
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.
Add new tab to editor, allowing user to select from available audience
types in order to grant access to their reports.
Co-authored-by: David Matamoros <davidmc@moodle.com>
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>
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.
Implement base filter classes as well as commonly used filter types
(e.g. text, date, select, etc).
Filters are used in reports to allow users to narrow down the data
that is being displayed.
Co-Authored-By: Paul Holden <paulh@moodle.com>
Marina Glancy