Use in the new browse users system report, to which it is quite
specific. The filter itself is a like for like replacement of the
pre-existing filter on the same page, and is really a combination
of existing role/category/course filters.
- The report 'Browse list of users' has been converted to use Report
Builder.
- Behat tests have been fixed and some test have been deleted for not
being relevant anymore.
Update existing entity to define remaining report elements. Add new
report source joining the entity to the user entity to provide data
for the reportbuilder editor.
Allow adhoc tasks to implement this method, so they too can have
descriptive names for themselves. Default implementation added to
return the class name itself.
Allows display_size to use a fixed unit for easy comparison of
multiple results, and fixed decimal places for the same reason.
Improves behaviour by using consistent decimal places and a
consistent space before the unit (the previous one only has a space
before 'bytes', not before 'KB').
Of existing uses, all the ones that displayed a 'maxbytes' type
configuration setting (which are likely to have an 'exact' size
and would be better shown as 512 KB rather than 512.0 KB) have been
changed to use 0 decimal places, to preserve previous behaviour.
All the uses which were showing an actual file or memory size have
been left as default (1 decimal place).
Convert to system report API provided by Report builder. The entity
defined the column and filters, which are used by the system
report class we have created.
Report actions are also defined in the system report.
Improve the Test outgoing mail configuration admin page adding:
- Timestamp to the subject and message text.
- Additional subject text to the current text subject.
- From field (username or email) to send the test email from the that Moodle user.
When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
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).
Paul Holden