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.
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.
This ensures compliance with the following WCAG criterion:
"H71: Providing a description for groups of form controls using fieldset
and legend elements".
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.
Allow report implementations to control what is shown when no results
are found for the current report+filters. Allow setting to null to
allow calling code to omit this notice entirely.
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.
The new entities encapsulate related data for easier re-use across
reports, and are also intended to replace similar columns/filters
from the current enrolment entity.
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 that when the user entity is added multiple times to a report,
when there are custom profile fields, each of those gets a unique table
alias per-entity.
The component the audience belongs to is used by the cards exporter
for rendering the editing interface. Avoid duplication in determining
this value by defining appropriate method in the base class.
During request lifecycle ensure that column, filter and condition
persistents are only loaded a single time to prevent additional
database reads.
Provide invalidation method, used by the report helpers, to ensure
that the persistents are re-loaded appropriately.
Co-authored-by: Marina Glancy <marina@moodle.com>
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).
Paul Holden