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.
The simple pattern matches were conflicting in some situations. To make
this backwards compatable we need to convert it to a Regex pattern match
instead, and provide the quoted and unquoted variants.
There were two issues here:
* I am on the [categoryname] category page page (duplicated page)
* the wrong URL was being used
Since an incorrect URL was used I felt it safe to rename the step from
'category page page' to 'category page'.
This commit makes the following improvements to core page resolverss:
* allows for mixed case naming (course, Course, etc.)
* allows fields other than the idnumber to be specified:
** course: idnumber, shortname, fullname
** course category: idnumber, name
Whilst some of these fields are not unique, they will typically be
unique in most test scenarios. Where they are not then the idnumber
should be used in preference.
Instead of passing querying for the root element again by its ID
which changed in this issue, use the already existing root element
at the beginning of this Mustache JS code. It also makes maintenance
simpler in the future.
