Choose aggregation method that has availability across all
supported databases; and allows sorting.
"Comma separated distinct values" doesn't fulfill either of
these criteria.
Before this change if a new post was made after the digest time but
before todays daily digest had been sent the run time on the digest
would be set to the next day resulting in no digest being sent to
the user.
By adding the server midnight to the custom data on the task we
ensure that in this case a new adhoc task is created for the next
day leaving the current one to get processed.
Server midnight is used so that if the digest time setting is
changed we would not get two tasks queued for the same day.
Before this patch the exported users (to csv file that jmeter consumes)
were all the enrolled users in the test course. And that's ok when the
number of users enrolled match the number of concurrent threads planned
for a jmeter plan (each thread is a user).
But when both numbers don't match, that can lead to the jmeter plan
not behaving as expected, because it iterates over the excessive users
in the file, leading to some users having run 5 loops, others 4...
The only way to make results more consistent is to, always, ensure that
the number of users exported for the plan match the plan size and not
the site size.
And that's what this issue exactly does, restrict the export to the
number of threads that the plan will have. So every user always runs
the very same number of loops.
Statically cache list of loaded reports during request lifecycle,
this ensures that computationally heavy initialisation routines
in system reports are only executed once (e.g. the access tab).
This fixes an issue for system reports that are initialised with
parameters (such as the access report). Previously these parameters
were not preserved, when sorting/paging them via AJAX requests.
We now defer the initialisation of the report until the table
filterset has been set, ensuring all parameters are available.
This tab includes a system report that provides a listing of all
users who can access the report, taking into account all audiences
that have been created for it. Update page of users available
reports to obey audience configuration.
Fix filters JS form to ensure it is only loaded once.
Co-authored-by: Mikel Martín <mikel@moodle.com>
Add new tab to editor, allowing user to select from available audience
types in order to grant access to their reports.
Co-authored-by: David Matamoros <davidmc@moodle.com>
Create the base audience class, to be extended by all audience types
across the site. Implement types allowing audiences to be created per
user, cohort or system role assignment.
The helper class is used for interrogating report audience instances
and retrieving access lists of those users able to view specific
reports.
Co-authored-by: Paul Holden <paulh@moodle.com>
