More work built upon e76d99f2, we need to perform the alias processing
earlier to ensure that it works for system reports where user sorting
isn't the default.
- Add .visually-hidden to the Boostratp 5 bridge SCSS file
- Replace .sr-only occurrences with .visually-hidden
- Replace .dropzone-sr-only-focusable with .dropzone-visually-hidden-focusable
for consistency
This is extending work started in 8f32e623 that removed duplicate
fields when sorting user fullname columns (to ensure compatibility
across supported DBs).
We must now refer to these sorted fields by their alias in order to
ensure they continue working when processed from the report table.
Co-authored-by: David Carrillo <davidmc@moodle.com>
Use the new "counted recordset" DML API from 42664ee49a to obtain
the raw table data for reports. For those databases with defined
support for count window functions, this should give a performance
benefit by combining the count and main query into one request.
This change fixes an edge case that could be triggered by creating a
custom report that contained a filter instance that was active as both
a filter and condition, where the filter instance provides parameters
to it's SQL fragment.
There is only one such filter present currently with which we can test
this, see 2f9001cbe9.
Move the `get_name` method to the base report class, so that it can be
implemented by all report types. Provide a default implementation for
system reports based on the name of the class.
Use the name of the report as the caption. Target via Behat selectors.
Allow report implementations to control what is shown when no results
are found for the current report+filters. Allow setting to null to
allow calling code to omit this notice entirely.
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.
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>
Paul Holden