This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
It is perfectly valid to have a query like:
Match None of the following:
- Role is ANY of the following:
-- 'Teacher'
-- 'Editing teacher'
-- 'Manager'; AND
- Keyword is NONE of the following:
-- 'Kevin'
However, due to the way in which the query is constructed, this leads to
a query which includes
WHERE NOT ef.id IS NOT NULL
AND NOT
u.id IN (SELECT userid FROM {role_assignments} WHERE roleid IN (...) AND contextid IN (...))
AND NOT
NOT (u.firstname || ' ' || u.lastname LIKE '%Kevin%')
The use of NOT NOT is valid in Postgres, MariaDB, MySQL, and MSSQL, but
not in Oracle.
To counter this when the outer jointype is of type NONE, we must wrap
each of the inner WHERE clauses in a set of brackets, which makes the
query:
WHERE NOT ef.id IS NOT NULL
AND NOT
(u.id IN (SELECT userid FROM {role_assignments} WHERE roleid IN (...) AND contextid IN (...)))
AND NOT
(NOT (u.firstname || ' ' || u.lastname LIKE '%Kevin%'))
Whilst Oracle does not support the use of `AND NOT NOT ...`, it does support
`AND NOT (NOT ...)`
This is required to ensure regardless of user applied filters, only
members of groups visible to the user are ever fetched. This also
includes a fix to remove the groups filter option where no groups
mode is applied.
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.
This was originally intended to be a way for the calling code to specify
data as part of the table construction which could then be used as
appropriate. When the filterset was created the requirement for this
function no longer existed.
Removing this to simplify the API.
