Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

reportbuilder/API

From MoodleDocs
Revision as of 08:19, 20 June 2014 by John Okely (talk | contribs) (Fix displayfunc and selectfunc)

Back to Index

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.


Overview

Report Builder provides an interface to allow administrators to generate reports, customise their appearance, then make them available to groups of users. It is designed to be easily extensible, so developers can add to existing report sources and write their own to allow administrators to generate the kind of reports they are interested in.

The Report Builder API enables plugin contributors and Moodle core developers to create new sources that can be used by site administrators and teachers to generate and customise reports.

Elements

Core

The majority of the Report Builder's code lies in core\reporting, which is located in the 'reporting' folder in moodle. This houses the basic logic for reporting functionality and the base source class, core\reporting\base.

Tool

The viewing and creating of reports is handled in a tool, "tool_reportbuilder" which is located in admin/tool/reportbuilder.

Sources

All reports are based on a single source, which defines the relationships between tables in the databases (amongst other things detailed below).

A source class should exist in the relevant module's namespace (which is the module's Frankenstyle component name), under "reporting" (e.g. \mod_assign\reporting\submission). This means that the file should be located in the module's classes folder, in the reporting subfolder (e.g. mod/assign/classes/reporting/submission.php).

The class must extend report_builder_source_base.

A source consists of:

  • A base table: Defines what table all reports from this source will be based off (base)
  • A join list: Defines what tables should be joined to the base table (joinlist)
  • Column options: Defines which columns from each table should be available in the report (columnoptions)
  • Filter options: Defines what fields can be used to filter the results in the report (filteroptions)
  • Default columns: Defines what fields will be selected when a report is first created from this source (defaultcolumns)
  • Default filters: Defines what filters will be available when a report is first created from this source (defaultfilters)

Construction

defined('MOODLE_INTERNAL') || die();

class \mod_choice\reporting\choice extends \core\reporting\base {

   use \core\reporting\common\user;
   /**
    * Constructor for defining a report builder source object.
    */
   function __construct() {
       $this->base = '{choice_answers}';
       $this->sourcetitle = get_string('sourcetitle', 'mod_choice');
       parent::__construct();
   }

To construct a source, all you have to do is set 'base' to the table name with no prefix, in braces, e.g. "{choice_answers}" and set the source title. The 'sourcetitle' is retrieved from the relevant module's language file (in this case, mod_choice) The constructor automatically calls the functions to define the structure of the source. It is possible to define all the information by overriding __construct and filling the base, joinlist, columnoptions, filteroptions and defaultcolumns directly, but this quickly becomes large and unwieldy. A number of helper traits can be used. This will assist the inclusion of common fields and filters in the source. The available traits are:

  • \core\reporting\common\user
  • \core\reporting\common\course
  • \core\reporting\common\course_category

We will go through the methods to fill out the rest of the sources properties below.

define_joinlist

/**

* Other tables that are related to this source.
*
* @return array An array of \core\reporting\join objects.
*/

protected function define_joinlist() {

   $joinlist = array(
       new \core\reporting\join(
           'choiceoptions',
            'LEFT',
           '{choice_options}',
           'choiceoptions.id = base.optionid'
       ),
       new \core\reporting\join(
           'choice',
           'LEFT',
           '{choice}',
           'choice.id = base.choiceid'
       )
   );
   $this->add_user_table_to_joinlist($joinlist, 'base', 'userid');
   return $joinlist;

} define_joinlist is used to define all of the possible other tables that will link with the base one. The \core\reporting\join object in this example has four properties.

  1. Table alias
  2. Join type
  3. The table name
  4. SQL join code (i.e. what would ordinarily come after JOIN ON)

The following helper functions can be used in the joinlist.

  • add_user_table_to_joinlist (use the \core\reporting\common\user trait)
  • add_course_table_to_joinlist (use the \core\reporting\common\course trait)
  • add_course_category_table_to_joinlist (use the \core\reporting\common\course_category trait)

The user tables are added using the helper function in this example.

define_columnoptions

/**

* Columns that can be selected in this report.
*
* @return array An array of \core\reporting\columnoptions.
*/

protected function define_columnoptions() {

   $columnoptions = array(
       new \core\reporting\column_option(
           'choice',
           'title',
           get_string('name', 'mod_choice'),
           'choice.name',
           array('joins' => 'choice')
       ),
       new \core\reporting\column_option(
           'choice',
           'choiceoption',
           get_string('choicename', 'mod_choice'),
           'choiceoptions.text',
           array('joins' => 'choiceoptions')
       ),
       new \core\reporting\column_option(
           'choice',
           'timemodified',
           get_string('timemodified', 'mod_choice'),
           'base.timemodified',
           array(
               'displayfunc' => 'nice_datetime'
           )
       )
   );
   $this->add_user_fields_to_columns($columnoptions);
   return $columnoptions;

} Column options are possible columns that can be used in the report. The \core\reporting\column_option array elements in the example are:

  1. The column type of the columns. Here I have defined three columns that will be under the 'choice' heading.
  2. The value of the column.
  3. The string for the column name.
  4. The field in the database. Here we have the alias and the field name.
  5. Further options
    1. If the field is not part of the 'base' table then the join should be included here.
    2. You can also specify a function to format the display of a column. In this example I am used one of the predefined display functions (nice_datetime). To use a custom display function, create a function with the displayfunc preceded by 'display_'. So for 'displayfunc' => 'berber_datetime', create the function 'display_berber_datetime' in your source class

Here are the helper functions which allow the inclusion of standard columns:

  • add_user_fields_to_columns (use the \core\reporting\common\user trait)
  • add_course_fields_to_columns (use the \core\reporting\common\course trait)
  • add_course_category_fields_to_columns (use the \core\reporting\common\course_category trait)

The user fields are added using the helper function in this example.

define_filteroptions

/**

* Filters that can be added to this report.
*
* @return array An array of \core\reporting\filter_option objects.
*/

protected function define_filteroptions() {

   $filteroptions = array(
       new \core\reporting\filter_option(
           'choice',
           'choiceoption',
           get_string('choicename', 'mod_choice'),
           'select',
           array('selectfunc' => 'choice_option_list')
       )
   );
   $this->add_user_fields_to_filters($filteroptions);
   return $filteroptions;

} It is possible to add filters to your report so that large reports can be condensed into a smaller and perhaps more meaningful display. The filteroptions array elements are:

  1. The column type.
  2. The value of the column. This should be the same as the column_option's value.
  3. The string for the name of the column.
  4. The type of filter this filter option will be. The default filter types are:
    1. cohort
    2. date
    3. enrol
    4. multicheck
    5. number
    6. select
    7. text
    8. textarea
  5. other options
    1. A select function can be specified here to return the information required for the filter. To use a custom select function, create a function with the selectfunc preceded by "filter_" Here we have created a very basic function to return the choice options.

Once again there are helper functions for adding typical filter options:

  • add_user_fields_to_filters (use the \core\reporting\common\user trait)
  • add_course_fields_to_filters (use the \core\reporting\common\course trait)
  • add_course_category_fields_to_filters (use the \core\reporting\common\course_category trait)

The user fields are added in this example

define_defaultcolumns

/**

* Defines the default columns when creating a report.
*
* @return array An array of default columns.
*/

protected function define_defaultcolumns() {

   $defaultcolumns = array(
       array(
           'type' => 'user',
           'value' => 'namelink'
       ),
       array(
           'type' => 'choice',
           'value' => 'title'
       )
   );
   return $defaultcolumns;

} It is possible to define default options that will included immediately after the source has been specified. These values can be edited and removed by the user if not required. The two elements of the array match with the first two elements of one of the column_options (column type and value)

define_defaultfilters

/**

* Defines the default filters when creating a report.
*
* @return array An array of default filters.
*/

protected function define_defaultfilters() {

   $defaultfilters = array(
       array(
           'type' => 'choice',
           'value' => 'choiceoption',
       ),
   );
   return $defaultfilters;

} It is also possible to define default filters that will included immediately after the source has been specified. Again, the user can edit or remove these filters later. The two elements of the array match with the first two elements of one of the filter_options (column type and value)

Custom Function

/**

* Custom function to return an array of choice options.
*
* @return array Choice options.
*/

function filter_choice_option_list() {

   global $DB;
   $choiceoptions = array();
   $records = $DB->get_records_sql("SELECT text FROM {choice_options}");
   foreach ($records as $value) {
       $choiceoptions[$value->text] = $value->text;
   }
   return $choiceoptions;

} Here is the custom function that we used to return the choice options in the filter. It retrieves all the possible options in the choice and returns the values.