Completed support for all join types (any/all/none) for enrolment
method and status filtering. This includes handling forced status
filtering where a user does not have the capability to view suspended
users, as well as handling front page (whole site) participants page.
The last access implementation also fixes an existing bug,
where it was assumed never accessed would be 0, when it also needed to
handle null to return correct results. Related userlib unit tests also
updated to reflect this, as well as some incorrect comment wording.
Created the participants_search unit testing file, including
tests for role, keywords, status and enroment method filtering.
Co-authored-by: Michael Hawkins <michaelh@moodle.com>
This change enables the gherkinlint rule to require a new line at the
end of the file. This change is in keeping with existing Moodle coding
style guidelines.
The gherkin-lint package now understands the use of "Examples" and
requries that their indentation be correct and consistent.
This change sets the indentatation for these to:
"Examples": 4,
"example": 6,
This is in-line with the examples given in the offical Cucumber/Gherkin
documentation at
https://cucumber.io/docs/gherkin/reference/#scenario-outline whereby the
Examples and individual rows of the Examples table are children of the
Scenario outline.
This is contrary to the default for Gherkin-lint which places them as
top-level nodes with an indentatio of 0, and 2 respectively.
Replace it for correct property_exists() when the element
being inspected is a property of object/class.
Amended and squased changes:
- keep mongo unmodified. The information is array, hence correct.
- fix a couple of messaging phpdocs that were incorrect.
Amended take#2:
- As far as mongo resturns BSONDocument that is ArrayObject, aka
implements ArrayAccess, we have decided to explicitly cast results
to array so existing array_key_exists() and other accesses will
continue working the same.
Two modes of visibility checking are supported, depending on the value
of the 'messagingallusers' site setting (site-wide messaging):
- If site-wide messaging is enabled, a user may only be returned in
search results if the searching user can view their profile somewhere
(either the site profile or any course profile).
- If site-wide messaging is disabled, a user may only be returned in
search results if the searching user shares a course with them and can
view their course profile in the shared course.
This had a relatively simply check for course profile visibility, which
meant that users in separate groups could see one another's profile.
This has been replaced with the more correct check in
user_can_view_profile().
* External authentication mechanisms (e.g. via oauth2, etc.) don't store
password in the user table, so we shouldn't be requiring password in
such case when creating users via the core_user_create_users WS
function.
