Previously the `moodle/course:bulkmessaging` capability controlled
access to the entire bulk actions menu for course participants,
rather than just those actions related to messaging.
- Replace all individual calls to add all columns, filters and
conditions on the cohorts datasource with the new
method add_all_from_entities().
- Replace all individual calls to add all columns, filters and
conditions on the courses datasource with the new
method add_all_from_entities().
- Replace all individual calls to add all columns, filters and
conditions on the users datasource with the new
method add_all_from_entity().
The "Start page" user preferences page has been reviewed to
consider the new $CFG->enabledashboard setting.
The "Dashboard" won't be displayed in the list if it's disabled.
Besides, the default value is now calculated calling the new
get_default_home_page() method.
Custom profile fields allow for shortnames containing mixed character
casing, which should also be supported within the user fields API
when retrieving said custom fields.
Given that the DML libs convert all selected columns to lowercased
equivalent, we need to do the same when requesting custom fields to
ensure calling code doesn't try to access `->profile_field_Foo`
property when the DB returns `->profile_field_foo` instead.
Implement module for filters editing, allowing the report
editor to define which filters are available when users
are viewing the report.
These filters allow those users viewing the report to further
limit the data being displayed (after conditions have been
applied), by selecting their own values for each filter.
Co-authored-by: Paul Holden <paulh@moodle.com>
Report conditions allow report creators to limit which data
is displayed when the report is viewed. Users viewing the
report cannot override these condition values.
Implement UI elements for editing columns of a report, taking their
definitions from the selected datasource.
Co-authored-By: David Matamoros <davidmc@moodle.com>
Co-authored-By: Mikel Martín <mikel@moodle.com>
Implement elements for creating/editing reports, along with
new system report for listing and accompanying JS modules for
user interaction.
Create "Users" datasource as proof-of-concept.
Co-authored-By: Paul Holden <paulh@moodle.com>
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).
There were existing places each doing its own checks similar to the ones
covered by the newly added core_user::awaiting_action() method. This
patch replaces those custom checks with this new API call.
Create a new profile field type, move all existing content of the fields
'icq', 'skype', 'aim', 'yahoo', 'msn' and 'url' in the mdl_user table to
theses new profile fields if needed.
AMOS BEGIN
MOV [aimid,core],[aimid,courseimage,profilefield_social]
MOV [yahooid,core],[yahooid,profilefield_social]
MOV [skypeid,core],[skypeid,profilefield_social]
MOV [icqnumber,core],[icqnumber,profilefield_social]
MOV [msnid,core],[msnid,profilefield_social]
MOV [webpage,core],[webpage,profilefield_social]
AMOS END
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.
The purpose of this external function is to provide data for
asynchronous user selectors and similar widgets. It allows to search
users matching the given query in their name or other available identity
fields.
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).
