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.
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.
Use native ANSI SQL syntax for numeric comparisons where possible,
define filter API for the case where filters must re-use the given
field SQL while ensuring uniqueness of any field parameters.
Currently only necessary in the category filter type.
Ensure column and filters provided by each source have sufficient
coverage. Re-factor individual entity/helper class tests to test
their own specific implementation only.
Remove now-defunct test fixtures.
The base time allows for the setting of the "current time" for the
purposes of the schedule test against recurrence configuration.
We should ensure the generator method allows this property so that
it can be used when calculating the initial "next send time" of the
schedule upon creation (and avoiding excessive recursion when the
actual current time is used for the calculation).
