There are related elements that deal with events in Moodle, such as event lists and event monitoring rules. Both will be covered in the subsections that follow.

Event lists

Most actions in Moodle have the ability to trigger an event. You can take a look at the list of all the available events by going to Reports | Events list. This list will grow over time with internal and external events being added.

Each event comprises the following elements:

Element	Description
Event name	Name of the event and internal unique identifier.
Component	The Moodle component that the event belongs to. This is usually core, a course module, or some other part, such as statistics or logs.
Education level	There are three levels: Participating, Teaching, and Other.
Database query type	There are four query types that can occur: read, update, create, and delete.
Affected table	Database table being affected.
Since	Moodle version when the event has been introduced.
Legacy event	Event triggered in the legacy log store (this only contains events from version 2.6).

You have the ability to filter the list by Name, Component, Education level, and Database query type. By clicking on an event name, you will be able to see a more detailed presentation of the same information. Here, we have selected the User added to cohort event:

In addition to Explanation of the event, the screen shows Parent Event and a list of Plugins observing this event. While the explanation is self-explanatory, the latter two pieces of information require some explanation:

• Parent Event: Internally, events are organized in a hierarchy. For an administrator, this is done only for information.
• Plugins observing this event: These are the plugins that monitor the event. Here, we have a log store manager (called tool_log), the event monitor itself, and the Cohort sync module, which ensures that every time a user is added to a cohort they will also be enrolled in linked courses.

Event monitoring rules

Administrators and teachers have the ability to define events to which one can subscribe. These patterns of activities are represented as rules that contain an event as well as a frequency. Once such a pattern has been detected, an event will be triggered, which then sends a message to all subscribers.

While users with editing teacher rights have the ability to set up their own rules at the course level, you, as the administrator, are more likely to define a set of required rules to which teachers will subscribe. Learners can also subscribe to rules once they are granted the tool/monitor:subscribe capability.

First of all, you will have to enable event monitoring by navigating Reports | Event monitoring rules. Once you've done this, you have the ability to add new rules on the same page and subscribe to those rules via the Event monitoring link that now appears on the Preferences page.

Let's add our first event rule via the Add a new rule button by going to Reports | Event monitoring rules. Once you have entered Rule name, you have to select Area to monitor. The values in the list are identical to the ones you came across in the Component dropdown, as seen in the preceding events report. Once chosen, the Event list will be populated with all the available events that the component supports. The description is optional, but it is recommended that you provide this for potential subscribers. Notification threshold in minutes specifies the number of events within a specified time period that are required for Notification message to be sent. The body of this message can include any or all of the following placeholders:

• {link}: Link to the location of the event
• {modulelink}: Link to the area monitored
• {rulename}: Rule name
• {description}: Description
• {eventname}: Event
  

Any user with the tool/monitor:subscribe capability now has the ability to subscribe to events via the Event monitoring link in the Miscellaneous section in their Preferences.

Before subscribing to a course, you will have to Select a course that is monitored (Site covers all the courses). From now on, a notification message will be sent when the subscribed rule is triggered.

The log manager is an internal component that monitors events and passes data to all enabled log store plugins. Moodle comes with a predefined log manager; however, it is possible that this will be replaced by other log manager plugins. For now, as an administrator, you have no means of configuring the log manager.

A log store plugin is associated with a physical log store and dictates what data is stored and read in the log store, respectively. Moodle ships with three log store plugins, namely Standard log, External database log, and Legacy log (Plugins | Logging | Manage log stores). We are going ignore the legacy log as this will be discontinued over time. The standard log is the replacement for the legacy log, which supports all new logging concepts and also provides better performance. In its Settings, you can specify whether to Log guest access, how long to Keep logs for, and Write buffer size.

You can configure an external database log store if you wish to write logging information to a database that's separate from Moodle. This is useful if you wish to improve performance and/or if you wish to collect data for more detailed analysis or learning analytics. This is shown in the following screenshot:

By default, the same databases are supported as when we installed Moodle. Also, the database host, user, password, and name settings are identical to the ones we covered in Chapter 1, Moodle Installation. Additionally, you have to specify Database table, the structure of which has to be identical to the one stored in mdl_logstore_standard_log. Make sure that you test the connection (the link is at top of screen); if successful, the check will display the columns that the external table contains.

You also have the ability to specify a number of settings for a persistent database connection. This is useful if you have a lot of logging traffic on your site and performance is an issue.

Now comes the interesting part of the external log store plugin. You have the ability to specify a number of filters, which will then be applied when storing the data:

There are two types of scenarios that tell you when filtering logs is useful: when privacy regulations do not allow the storing of actions of certain users or types (refer to Chapter 11, Moodle Security and Privacy) and when reporting from the log store does not require certain actions; this will also have a beneficial impact on performance.

At the time of writing this, there is only a single log storage plugin that's available in the Admin tools section of https://download.moodle.org/ (this is xAPI; it emits events from the Moodle Log store as xAPI or the TinCan statements). However, it is expected that this number will increase in the near future. The support of NOSQL databases will be particularly interesting, and these have proven beneficial for a wide range of learning analytics reports and analyses.

A report is pretty much what you expect it to be: a module that generates a view of data. There are two types of reports in Moodle: ones that are supplied with data from a log store and others that are being generated on the fly without log store input. You can view a list of reports by going to Plugins | Reports | Manage reports:

You can see when a report requires a log store and, if so, which ones are supported. Initially, we will focus on reports that are based on log stores.