- Show a toast notification when saving an audience
- Add form change checker when adding a new audience to prevent user from navigating away if it is not saved
- Remove expand/collapse animation in audience sidebar to be consistent with editor
Co-authored-By: Paul Holden <paulh@moodle.com>
- Don't allow to set a report name containing only blank spaces when
creating a new report or editing an existing report name.
- Removed TODO from code related to MDL-71086
This tab includes a system report that provides a listing of all
users who can access the report, taking into account all audiences
that have been created for it. Update page of users available
reports to obey audience configuration.
Fix filters JS form to ensure it is only loaded once.
Co-authored-by: Mikel Martín <mikel@moodle.com>
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>
Create the base audience class, to be extended by all audience types
across the site. Implement types allowing audiences to be created per
user, cohort or system role assignment.
The helper class is used for interrogating report audience instances
and retrieving access lists of those users able to view specific
reports.
Co-authored-by: Paul Holden <paulh@moodle.com>
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
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>
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.
