Ensure that provided columns and filters for each use appropriate
checks to determine their availability (based on user permissions,
etc), rather than conditionally adding them to the entity.
When doing so from calling code, the property is not persisted when
filtering/paging (or any AJAX interaction); instead, it should be
set from within the report instance itself.
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.
To be integrated as part of MDL-81266
When running PHPUnit 9.6 we get the following deprecation warnings:
"assertObjectHasAttribute() is deprecated and will be removed in PHPUnit
10. Refactor your test to use assertObjectHasProperty() instead."
So we replace all instances of assertObjectHasAttribute with
assertObjectHasProperty.
PHPUnit justifies the change with:
> PHPUnit currently refers to "fields" (see above) as "attributes". This
> is (or will become) confusing considering the introduction of
> attributes in PHP 8 and their support in PHPUnit. PHPUnit will be
> changed to use the term "property" instead of "attribute" where "field"
> is meant.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
To be integrated as part of MDL-81266
When running PHPUnit 9.6 we get the following deprecation warnings:
"assertObjectNotHasAttribute() is deprecated and will be removed in PHPUnit
10. Refactor your test to use assertObjectNotHasProperty() instead."
So we replace all instances of assertObjectNotHasAttribute with
assertObjectNotHasProperty.
PHPUnit justifies the change with:
> PHPUnit currently refers to "fields" (see above) as "attributes". This
> is (or will become) confusing considering the introduction of
> attributes in PHP 8 and their support in PHPUnit. PHPUnit will be
> changed to use the term "property" instead of "attribute" where "field"
> is meant.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
Allow them to be edited during report creation/updating, display in
report listings table with filtering, and implement tag callback to
allow them to be discoverable across the site.
The column type determines the available aggregation options present
for the column. Custom fields of type "select" should be considered as
text fields for this purpose, because their stored value represents
the index to their available options, rather than having any distinct
meaning of it's own for display.
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
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.
Courses, categories, users & cohorts each have a configurable `theme`
attribute - ensure reporting on said value is consistent across all the
corresponding entities.
