User Tools
This is an old revision of the document!
Table of Contents
Configuration
Dashboard Block
the configuration of the query and the multiple output options is the most important activity related to tis block setup. It requires:
- A good knowledge of the Moodle database structure
- A good knowledge of SQL and limitations
- A sufficiant knowledge of what the individual data fields represent and in what context and perimeter they can be used.
If you have those prerequisites, you are ready to do a lot of things with the Dashboard block.
Remind here that the Dashboard bloc can access to any data stored into Moodle and thus it's configuration may not be allowed in an uncontrolled way.
there are 6 main steps in setting up a dashboard query:
- Carefully identify in which tables and which fields are the data that represents the query
- Identify the dimensions of sorting and filtering
- Write and test the base query form in a DB client
- Copy the query in the dashboard
- configure the output (data tables or graphs)
- Setup accessories, (filters, parameters, colorizers, sub-totals, summators, etc).
Think about the problem (identify the query)
A Dashboard will NOT be able to answer to any demand. Usually, the addressed question must have an answer that can be synthesized within a single unique Query, giving a single aggregated composite output. As the block post-processes the given SQL to feed the query accessories (such as filters, or params), some complex query forms may be not supported.
In general, any results that comes out from simple JOINS (INNER, OUTER or LEFT) among a set of tables will work fine. Some queries using subqueries may work, Union or intersects may work on simple output, but some accessories may crash the query if activated.
Identify dimensions for sorting or filtering
the Dashboard block is designed for administrators being able to setup a query and additional dynamic tools addressed to the dashboard end users. Filters will provide multiple derivated partial views of the same output data. Parameters also will allow to change the initial perimeter of the extracted data, such as date ranges, ou value ranges, providing a lot of possible distinct reports with only one generic query.
Usually a data query will output a set of columns (data fields), which can be classed into the following categories :
- The identifier(s)
- The useful data (the really observed values)
- The contextual dimensions (that split the data space into local contexts)
- the technical data (that helps to calculate, format, or build other final results)
Filters usually will be defined upon the contextual dimensions, while parameters may usually affect usefull or technical values.
Ecrire et tester la requête de base
Vous utiliserez pour cela un client standard de votre base de données. Ce test permet de vérifier que la requête de départ fonctionne correctement et qu'elle produit bien des données cohérentes.
Les pièges à éviter
- Faire particulièrement attention à la première colonne extraite dans la requête. Il doit s'agit d'une donnée unique valant pour clef. Si tel n'est pas le cas, le résultat apparent semblera avoir perdu des données.
- Utiliser des requêtes composées (UNION, INTERSECT) dans lesquelles le placement de certains compléments automatiques de SQL ne peut pas se faire.
- Utiliser des requêtes imbriquées complexes mettant en jeu de nombreuses séquences ORDER BY ou GROUP BY.
Mettre en place la requête
La mise en place de la requête dans le tableau de bord est la première chose à faire réellement dans le tableau de bord.
- Passez le cours en mode édition
- Editez les paramètres du bloc Tableau de Bord à configurer
- Dépliez la rubrique Paramètres du tableau de bord
- Cliquez sur Accédez à la définition du tableau de bord
Le premier onglet est là où vous allez poser la requête.
Détail des écrans de configuration
