Friday, August 14, 2015

Moodle Configurable Reports Plugin All Variables and Filters

Configurable Reports is a popular plugin for Moodle that allows administrators to create custom reports for Moodle and make them available to their end users. In working with this plugin I have noticed that it can be difficult to track down all the variables and filters you can use in creating reports. Below are a list of all of the options.

Variables

%%CATEGORYID%%
%%COURSEID%%
%%CURRENTUSER%%
%%DEBUG%%
%%FILTER_VAR%%
%%STARTTIME%%','%%ENDTIME%%
%%USERID%%
%%WWWROOT%%

Filters

%%FILTER_CATEGORIES:
%%FILTER_COURSEMODULEID:
%%FILTER_COURSEMODULEFIELDS:
%%FILTER_COURSEMODULE:
%%FILTER_COURSES:
%%FILTER_COURSEENROLLEDSTUDENTS:
%%FILTER_USERS:
%%FILTER_ROLE:
%%FILTER_SEARCHTEXT:
%%FILTER_SEMESTER:
%%FILTER_STARTTIME:
%%FILTER_ENDTIME:
%%FILTER_SUBCATEGORIES:
%%FILTER_COURSEUSER:
%%FILTER_SYSTEMUSER:
%%FILTER_YEARHEBREW:
%%FILTER_YEARNUMERIC:

Using Variables

Variables can be used anywhere inside of your SQL query. 

Using Filters

When using a filter you need at least one static WHERE condition then you list one or more filters. For example

WHERE 1
%%FILTER_COURSES:c.id%%

You can technically add multiple filters, but once a user applies one filter to a report all filters for report are applied. So it can be a little tricky to have multiple filters on the same report. For example if you add a course and date filter to a report, then if you just want to filter by course you have to make sure your date filters are set to date range that covers all courses.

Many of the filters are hard code to be drop down menus which are sorted by database id number instead of alphabetically. This can be problematic if you have a large number of users, courses, or categories. However, you can use one search text filter per report, which can be used to work around the issue in some cases.

Many filters require a logical operator to specify how the filter works. For example
%%FILTER_STARTTIME:l.TIME:>%% %%FILTER_ENDTIME:l.TIME:<%%

Tuesday, May 12, 2015

Moodle 2.9 Top 5 New Features for Admins


Moodle 2.9 was release earlier this week. Here are my top five new improvements for administrators

Allow backup and restore on the front page 

http://tracker.moodle.org/browse/MDL-31500

Backup report again links to the individual course backup
summaries 

http://tracker.moodle.org/browse/MDL-30937

Assign global roles using CSV upload

http://tracker.moodle.org/browse/MDL-15187


CLI version of admin/replace.php

http://tracker.moodle.org/browse/MDL-25763

Configure temporary file deletion, to avoid moodledata/temp/backup filling up the filesystem

https://tracker.moodle.org/browse/MDL-32547




Friday, April 24, 2015

Improving Moodle Web Services Usability

The Good

Moodle, as of the version 2 release, includes a built-in Web Services (WS) API that supports a variety of WS protocols including SOAP, REST, and XML-RPC. Since the API is built-in it's generally available whether the site is self-hosted or commercially hosted. The API is easily extensible to add greater functionality. The API provides a single standard method for WS for Moodle simplifying what was a more complex patchwork of third-party solutions.

The Bad

In my experience with LMS development, WS libraries are typically used to provide realtime integrations between specialized third-party software such as a student management system or a content repository. The core Moodle WS library is poorly suited to this use case because it doesn't provide functions to find specific objects in the Moodle database using an arbitrary matching field. This is an unfortunate oversight given Moodle's otherwise excellent support for this methodology with its consistent use of the ID Number field throughout its system. Without being able to do these targeted matches against a value known by the third-party software, one has to rely on function calls to get the entire list of objects (example full user list). This is simply impractical from a performance perspective for any realtime system of scale.

We ran across this problem during a recent project creating an integration between a membership portal and a Moodle 2.7 site. 

We did some research and found that:
  1. There is a related improvement request in the Moodle development backlog see tracker https://tracker.moodle.org/browse/MDL-26886.
  2. Community member, Craig Baker,  submitted a conceptual solution and prototype code in the comments to address the issue. Craigs tracker profile https://tracker.moodle.org/secure/ViewProfile.jspa?name=cbaker118.

The Fix

Using the extensible nature of the WS API, we created a local plugin to allow clean and easy installation of our additions. We based the new calls on the conceptual solution posted by Craig. Many thanks to Craig for his contribution. 

You can download a copy of the eLC WS library from git at

Be aware this was an emergency solution that to date has only been used on one Moodle site. As always with contributed code you should test for your particular use case. Please share your experiences with the code if you decide to try it and whether there are any improvements you would like to see.

This solution only really deals with allowing enrollment of a user into a course without knowing the users internal database ID number. Additional functions are needed to fully address the issue across all aspects of the API. As we do more WS related projects we plan to add additional functions.

Friday, April 17, 2015

Use apache mod_deflate to make your Moodle website faster

Mod_deflate is an Apache web server module that uses compression to reduce the bandwidth needed to send web pages between the server and the end user's computer.

See http://httpd.apache.org/docs/2.4/mod/mod_deflate.html

Modern web applications such as Moodle send a lot of text from HTML code, to CSS styles, to javascript, all of which can achieve high compression rates.

So how does reducing bandwidth usage make your website faster? It's actually a bit of a trick. The website itself probably isn't really faster in terms of the number of users or pages it has the capacity to generate. Each page probably will take about the same build time as before on the server. In fact if your server's undersized in terms of CPU resources it might even reduce the server's overall capacity. But for the end user the perceived responsiveness of the website is significantly increased. This is because it takes a lot less time for the page to be transported from the server to the user's computer. This can have a significant impact on user satisfaction and is relatively easy to setup for knowledgable administrators. On a recent engagement, I actually saw a 2-3 second improvement in page load times for the end user, even while accessing from the local campus network. Needless to say the Moodle administrator for this site was very happy with the improvement and you will be too!