Convert to system report API provided by Report builder. The entity
defines the columns and filters, which are used by the system
report class we have created.
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.
Convert to system report API provided by Report builder. The entity
defined the column and filters, which are used by the system
report class we have created.
Report actions are also defined in the system report.
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.
Before, we had each redirect test duplicated: one for the native
redirects via native cURL, second for our emulated implementation. Now
all redirects are always emulated so there is no need to have them
tested twice.
The security problem here was that only the first and the last URL in
the redirect chain was checked by the security helper. This patch forces
the curl wrapper to always emulate cURL redirects and check every
redirect URL in the chain before actually visiting it.
The new parameter of curl_security_helper::url_is_blocked() introduced
in MDL-71916 became part of the API. Even if we reverted it quickly,
someone can use a released Moodle version that has that parameter in
place. For that reason and also to avoid potential troubles in the
future (e.g. when yet another argument would be added to this method),
we need to make it clear that the second parameter of this method should
never be used again.
Poor $maxredirects, you did not live long with us. Oh well.
This reverts the original fix introduced in MDL-71916. It introduced an
extra native cURL call inside curl_security_helper to check if the given
URL triggers a redirect to a blocked URL or not.
Shortly after the release, a couple of regressions were reported as a
result of the integrated solution. It was agreed to revert the fix and
progress with implementing an alternative approach.
