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.
Course category fields were changed en masse from simple select
elements to autocompletes in 93d72205, but weren't defined as
required fields. This could lead to exceptions and/or unexpected
behaviour if their values were cleared prior to form submission.
Fetching user tours used to fail on external_api::validate_context() and
require_login() calls if the user did not have the site policy agreed.
The patch introduces a check to see if the user is fully set up and
ready to use the site before attempting to load the tours.
The simple pattern matches were conflicting in some situations. To make
this backwards compatable we need to convert it to a Regex pattern match
instead, and provide the quoted and unquoted variants.
There were two issues here:
* I am on the [categoryname] category page page (duplicated page)
* the wrong URL was being used
Since an incorrect URL was used I felt it safe to rename the step from
'category page page' to 'category page'.
This commit makes the following improvements to core page resolverss:
* allows for mixed case naming (course, Course, etc.)
* allows fields other than the idnumber to be specified:
** course: idnumber, shortname, fullname
** course category: idnumber, name
Whilst some of these fields are not unique, they will typically be
unique in most test scenarios. Where they are not then the idnumber
should be used in preference.
Some fields were being hidden based on whether the service was set up
for internal service use or was a service shown on the login page.
These fields refer to OAuth 2 logins and must be configurable for both
kinds of services.
Shamim Rezaie