Available update notifications

Available update notifications
Project state	Working on spec
Tracker issue	MDL-20438
Discussion	N/A
Assignee	David Mudrak and Marina Glancy

Moodle 2.3

Goals and milestones

Keeping a Moodle site up-to-date is the primary way of keeping it secure. We should encourage admins to update their sites to the most recent stable version on a regular basis. As a first step, for Moodle 2.3, we will implement a notification infrastructure to:

• notify admins about Moodle core updates available for their site; and
• notify admins about available updates for the contributed plugins installed on their site.

Notifications will be displayed at the Admin notifications page and Plugins overview page. In their messaging preferences, admins will be able to set up notifications to be sent by email, Jabber, etc. (using standard messaging features).

Scrolls of Wisdom

To display these notifications (and eventually send an email/message via the inbuilt messaging system) we need to achieve the following.

Define a primary source that knows what the most recent version of Moodle is available

At the moment, the download.moodle.org server seems to be place. TODO: How is the information stored there? Is it only in version.php? How do ZIP packages in Moodle core get to this server?

Define a primary source that knows what the most recent version is for each contributed plugin

This is definitely the new Plugins repository at http://moodle.org/plugins.

It seems to be reasonable to aggregate these two sources into a single place. This could be either the download server, the Plugins repository or something new like api.moodle.org or meta.moodle.org.

Communication protocol, or There and Back Again, or The Hobbit

There have been several suggestions of how the information about the available updates would be transferred from primary sources to target sites.

Generated XML files

This was proposed by Petr in October 2009 and is described at the Upgrade notification page. The format itself (XML) does not matter much and can be replaced by JSON or another format. The pros of this approach is that these files can be generated by a cronjob and cached to improve performance by reducing queries.

Using the current component_installer

This overlaps the previous approach. As Eloy pointed out, correctly, we already have a system like this in Moodle core. We use it for timezones and language packs at the moment. The pros of this is that we already use it and it seems to work pretty well.

Using heavy-weight web service

This project seems to be a good opportunity for the new WS framework we have. The source of information would expose the functionality via the WS API. REST/JSON format seems to be the way to go. See Specification - create a public web service server.

Using light-weight web service

As we do not need to cope with the access control here (and need something really cheap in terms of resources and performance), there is actually no need to use the underlying WS subsystem. The service can be produced by a simple script. There is already this approach used at http://lang.moodle.org/local/amos/rest/greylist?format=csv (see this commit to see how it is implemented).

Combining with current site registration system

The registration system is used to gather information about sites for statistical purposes. It could be enhanced to return information about current versions.

It is also wise to consider extending the system in the future. We should come up with a solution that is capable of not only providing a list of available updates, but also delivers the source code packages themselves.

Gathering statistical information during an update check

There is potential to gather information about the Moodle version and plugin versions related to a site.

At the moment, plugin downloads and page views is the only measure of plugin popularity we are capturing. If we can gather real information about plugins installed on sites and the number of instances in use, we can build up a realistic picture of the popularity of plugins, which can be returned as feedback to plugin developers and potential users.

Moodle version information is shared via site registration, however, not all sites register. Perhaps offering this service with a prerequisite of registering will encourage more admins to register, leading to a clearer picture of Moodle use.

The information gathered by this system could be seen as confidential, so it would be necessary to include an opt in/out mechanism similar to, or combined with, the current site registration. If this update notification system is to be constructed separately to the registration system, it may still be possible to gather information about Moodle and plugin versions during a passive update check. If the site transmits a list of plugins and versions, this could be paired to the sender's IP address and retained semi-anonymously.