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>
Implement elements for creating/editing reports, along with
new system report for listing and accompanying JS modules for
user interaction.
Create "Users" datasource as proof-of-concept.
Co-authored-By: Paul Holden <paulh@moodle.com>
Encode all popup data for report actions inside the action link
itself, because previously reloading a report via AJAX meant
actions no longer opened in popups, because the required JS was
absent from the page.
Instead of performing a page reload after resetting report filters,
we can use the fragment API to re-render the form after the user
presses the reset button.
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.
The report filter form is implemented as a dynamic form. Implement
accompanying AMD module for interacting with it here (applying and
resetting report filters).
Co-Authored-By: Mikel Martín <mikel@moodle.com>
Note that although system report persistents store user modified
and created fields, these are not the values of the user who did
either. Merely the user who first viewed the report.
Entities are re-usable collections of report columns and filters. When
creating system reports, we can re-use those elements from entities
without having to know specific details about their implementation.
They can be joined to reports, or other entities, using standard SQL
query syntax.
Define base classes, and create two example entities: course and user.
Co-Authored-By: David Matamoros <davidmc@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>
The column class encapsulates all data related to a report column. It
allows developers to define the type of data contained within it, in
addition to how that data is retrieved and formatted for users.
Report actions are used to define action elements that are added to
each report row. They define an icon and link, and can be used to
direct users to related pages according to the current row data.
