Make the display of both custom and user profile fields consistent in
column callbacks. The defaults for each should be considered when both
rendering the column data and also when aggregating them (specifically
for numeric columns to ensure calculations are accurate).
When such fields are filtered, and they have user defined default
values then we should also take that into account to ensure that the
same values rendered in columns can always be filtered for.
During this change, I've updated some of the variables to improve
readability and future maintainability of these classes. Annoyingly
there are a non-zero number of changes just for Oracle support.
All setUp(), tearDown(), setUpBeforeClass() and tearDownAfterClass()
must, always, call to parent, to ensure that everything is properly
set and cleaned.
While in a lot of situations this is not needed (parents may not
have anything to run), with PHPUnit >= 10 this can become more
important because we are going to move the reset code from current
placement @ runBare() to setUp()/tearDown().
Note that all the changes performed in this commit have been detected
and fixed by moodle-cs (ParentSetUpTearDownSniffTest).
Replace identical implementation of the same in various classes with
usage of the new trait. Implement constructor property promotion in
modified classes at the same time, to help clean up/clarify class
properties.
Where current implementation, and more specifically tests, rely on the
current time then replace that with the PSR-20 Clock from 298c13ac3b.
Applicable updates to the date filter and report scheduling calculation.
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.
Support localised float values in filter forms, so that locales that
use different decimal separators work as expected.
Note lack of current support in the date filter.
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.
As the number of report entity classes has grown, each having their own
manually defined table aliases, it becomes harder to ensure each of the
aliases are always unique across report sources.
We can remove that burden by ensuring table aliases are automatically
generated upon request.
We should verify that schedule and audience users are active accounts,
and that we don't try to send report schedules either from/to them if
they aren't.
We no longer need special handling of this field type, because it
now returns language strings rather than HTML markup for a checkbox
element on display.
Ensures cross-DB compatibility for all types of both custom and user
profile fields, specifically when they're filtered and/or aggregated.
Implement stress testing of both via appropriate report sources.
