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>
Ideally any new test should be using a class name matching
the file name, and to use namespace when clearly belonging to
a component (sub-namespace also allowed for better accuracy).
And, also, adding a @covers label to indicate which class
(preferred, method is also possible) is being covered with the test.
When the messagingallusers setting is disabled only contacts that are
on the same course as the user should be returned as results.
We can reduce the number of candidate users significantly by
pre-filtering them by being enrolled on the same courses as the user
performing the search.
Since we must also return the user themselves sometimes, even when they
are not enrolled on a course I used a UNION as the most efficient way of
retriving them, this meant that the order by had to reference returned
columns by number to be sufficiently cross-database compatiable.
This also implements the functionality for SCORM packages, which may
have SVG images embedded within their content which require loading
directly (and are only created by users with appropriate risk flag).
