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.
Default setting value for new instances is 0
Default setting value for existing instances is 1
to get same search results than before this setting exists
Setting messagingallusers = 1 for behat tests to simulate old versions functionality
Followup: MDL-63911
