You are on page 1of 3

This files describes API changes in analytics sub system,

information provided here is intended especially for developers.

=== 3.11 ===

* Final deprecation get_enabled_time_splitting_methods. Method has been removed.


Use
get_time_splitting_methods_for_evaluation instead.
* Final deprecation add_builtin_models. Method has been removed. The functionality
has been replaced with automatic update of models provided by the core moodle
component.
There is no need to call this method explicitly any more. Instead, adding new
models can be achieved
by updating the lib/db/analytics.php file and bumping the core version.
* Final deprecation - get_analysables(). Please see get_analysables_interator()
instead.
get_analysables_iterator() needs to be overridden by the child class.
* A new function get_executed_actions() has been added to \core_analytics\
prediction class
to get all (or filtered by action name) executed actions of a prediction

=== 3.8 ===

* "Time-splitting method" have been replaced by "Analysis interval" for the


language strings that are
displayed in the Moodle UI. The name of several time-splitting methods have been
updated according
to the new description of the field.
* A new target::can_use_timesplitting method must be implemented to discard time-
splitting methods that can not
be used on a target.
* Targets can now implement get_insight_body and get_insight_body_for_prediction to
set the body of the insight.
* Indicators can add information about calculated values by calling
add_shared_calculation_info(). This
data is later available for targets in get_insight_body_for_prediction(), it can
be accessed
appending ':extradata' to the indicator name (e.g. $sampledata['\mod_yeah\
analytics\indicator\ou:extradata')
* A new \core_analytics\local\time_splitting\past_periodic abstract class has been
added. Time-splitting
methods extending \core_analytics\local\time_splitting\periodic directly should
be extending past_periodic
now. 'periodic' can still be directly extended by implementing get_next_range and
get_first_start methods.
* Targets can now specify a list of bulk actions in bulk_actions(). core_analytics\
prediction_action is now
extending core_analytics\action and a new core_analytics\bulk_action class has
been added. Actions can now
specify a type in its constructor: core_analytics\action::TYPE_POSITIVE,
TYPE_NEUTRAL or TYPE_NEGATIVE. A list
of default bulk actions is available in \core_analytics\default_bulk_actions.
* The default suggested actions provided to users changed:
* For targets with one single sample per analysable (e.g. upcoming activities
due) the default actions are
Useful and Not useful.
* For targets with multiple samples per analysable (e.g. students at risk) the
default actions are
Accept, Not applicable and Incorrectly flagged.
* The suggested actions for the existing models have been reworded:
* Predictions flagged as "Acknowledged" in models whose targets use analysers
that provide one sample per
analysable (e.g. upcoming activities due) have been updated to "Useful" flag.
* Predictions flagged as "Not useful" in models whose targets use analysers
that provide multiple samples
per analysable (e.g. students at risk or no teaching) have been updated to
"Incorrectly flagged".
* \core_analytics\predictor::delete_output_dir has a new 2nd parameter,
$uniquemodelid.
* Analyser's get_analysables_iterator and get_iterator_sql have a new $contexts
parameter to limit the returned analysables to
the ones that depend on the provided contexts.
* Analysers can implement a context_restriction_support() method to restrict models
to a subset of the
contents in the site. Only CONTEXT_COURSE and CONTEXT_COURSECAT are supported.

=== 3.7 ===

* \core_analytics\regressor::evaluate_regression and \core_analytics\


classifier::evaluate_classification
have been updated to include a new $trainedmodeldir param. This new param will be
used to evaluate the
existing trained model.
* Plugins and core subsystems can now declare default prediction models by
describing them in
their db/analytics.php file. Models should not be created manually via the
db/install.php
file any more.
* The method \core_analytics\manager::add_builtin_models() has been deprecated. The
functionality
has been replaced with automatic update of models provided by the core moodle
component. There
is no need to call this method explicitly any more. Instead, adding new models
can be achieved
by updating the lib/db/analytics.php file and bumping the core version.
* \core_analytics\model::execute_prediction_callbacks now returns an array with
both sample's contexts
and the prediction records.
* \core_analytics\model::export() now expects the renderer instance as an argument.
* Time splitting methods:
* \core_analytics\local\time_splitting\base::append_rangeindex and
\core_analytics\local\time_splitting\base::infer_sample_info are now marked
as final and can not
be overwritten.
* Can now overwrite include_range_info_in_training_data() and
get_training_ranges() methods. They can be used to create time splitting
methods with a pre-defined
number of ranges.
* Can now overwrite cache_indicator_calculations(). You should return false if
the time frames generated
by your time-splitting method are unique and / or can hardly be reused by
further models.
* Can now overwrite valid_for_evaluation(). You can return false if the time-
splitting method can not be
used to evaluate prediction models or if it does not make sense to evaluate
prediction models with it,
as for example upcoming_periodic children classes.
* \core_analytics\local\analyser\base::get_most_recent_prediction_range has
been moved to
\core_analytics\local\time_splitting\base::get_most_recent_prediction_range
and it is not overwritable
by time splitting methods.
* Targets:
* The visibility of the following methods must now be public:
ignored_predicted_classes()
and get_insights_users()
* Prediction_actions() has now a 3rd parameter $isinsightuser. This parameter
is true
when we are listing actions for the user that will receives the insight.
* Can now implement a always_update_analysis_time() method so analysable
elements' timeanalysed is
only updated when analysable elements have been successfully evaluated. It is
useful for lightweight targets.
* Can not implement two new methods to tune the insights generated by the
model: get_insight_subject()
and get_insight_context_url().
* Analysers:
* The visibility of get_all_samples() method must now be public.
* get_analysables() method has been deprecated in favour of a new
get_analysables_interator()
for performance reasons.
* Can overwrite a new one_sample_per_analysable() method if the analysables
they use only have
one sample. The insights generated by models will then include the suggested
actions in
the notification.

=== 3.5 ===

* There are two new methods for analysers, processes_user_data() and


join_sample_user(). You
need to overwrite them if your analyser uses user data. As a general statement,
you should
overwrite these new methods if your samples return 'user' data. These new methods
are used
for analytics' privacy API implementation.

You might also like