MoodleDocs - User contributions [en]

Flashcard module

2018-03-30T15:37:45Z

Vf:

{{Infobox plugin
|type = Activity
|entry = https://moodle.org/plugins/mod_flashcard
|tracker = https://github.com/vfremaux/moodle-mod_flashcard
|discussion = https://moodle.org/plugins/mod_flashcard
|maintainer = [[User:Valery Fremaux|Valery Fremaux]]
|float = right
}}

The flashcard module allows editing and playing flashcards. Flashcards are a "memory training" device that uses the concept of repetition. Checking a flashcard deck will present the student the couples of relationships to be memorized. More often the associations are reviewed, deeper the memorization will be engraved into our memorial circuits.

The flashcard module has been useful for formative assessment of anatomy, histology and pathology concepts, definitions and images in the teaching of human and veterinary medicine at undergraduate and postgraduate levels.

==Features==

* Getting cards from a "matching question"
* Editing cards
* Multimedia cards: text, image, sound and image + sound together
* Automated backpropagation of cards (can be disabled)
* Customizable decks

==Configuration==

[[Flashcard module: Configuration Parameters]]

[[Flashcard module: Capabilities]]

==Usage==
===Adding new cards===
# Add new "Flash Card Set" into the course
# Enter required field "Name" and click "Save and display" button
# Click "Edit the cards" tabs - you will be brought to screen like below
[[File:flashcard1.jpg]]
# Click "Add three new questions" button
# Add text for questions and answers
# Click "Update" button

==Screens==

===Student Screens===

*[[Flashcard module: Freeplay Screen|Freeplay Screen]]
* Leitner Play Screens
** [[Flashcard module: Leitner Choose A Deck|Choose a deck to play with]]
** [[Flashcard module: Leitner Use A Deck|Use a deck]]

===Teacher Screens===

* Summary Screens
**[[Flashcard module: By User Summary|By User Summary]]
**[[Flashcard module: By Card Summary|By Card Summary]]
*[[Flashcard module: Edit Screen|Edit Screen]]

== See also ==
* [[Lesson_module#The_Flash_card_lesson|Flash card presentation]] in the [[Lesson module]] is an alternative to this module.
* Using Moodle [http://moodle.org/mod/forum/view.php?id=7180 Flashcard module forum]
* [http://docs.activeprolearn.com/en/doku.php?id=:mod:flashcard|Complete original documentation in English]

[[Category:Contributed code]]
[[Category:Medicine]]

[[fr: Flashcard]]
[[es:Módulo flashcard]]

Flashcard module

2018-03-30T15:36:56Z

Vf:

{{Infobox plugin
|type = Activity
|entry = https://moodle.org/plugins/mod_flashcard
|tracker = https://github.com/vfremaux/moodle-mod_flashcard
|discussion = https://moodle.org/plugins/mod_flashcard
|maintainer = [[User:Valery Fremaux|Valery Fremaux]]
|float = right
}}

The flashcard module allows editing and playing flashcards. Flashcards are a "memory training" device that uses the concept of repetition. Checking a flashcard deck will present the student the couples of relationships to be memorized. More often the associations are reviewed, deeper the memorization will be engraved into our memorial circuits.

The flashcard module has been useful for formative assessment of anatomy, histology and pathology concepts, definitions and images in the teaching of human and veterinary medicine at undergraduate and postgraduate levels.

==Features==

* Getting cards from a "matching question"
* Editing cards
* Multimedia cards: text, image, sound and image + sound together
* Automated backpropagation of cards (can be disabled)
* Customizable decks

==Configuration==

[[Flashcard module: Configuration Parameters]]

[[Flashcard module: Capabilities]]

==Usage==
===Adding new cards===
# Add new "Flash Card Set" into the course
# Enter required field "Name" and click "Save and display" button
# Click "Edit the cards" tabs - you will be brought to screen like below
[[File:flashcard1.jpg]]
# Click "Add three new questions" button
# Add text for questions and answers
# Click "Update" button

==Screens==

===Student Screens===

*[[Flashcard module: Freeplay Screen|Freeplay Screen]]
* Leitner Play Screens
** [[Flashcard module: Leitner Choose A Deck|Choose a deck to play with]]
** [[Flashcard module: Leitner Use A Deck|Use a deck]]

===Teacher Screens===

* Summary Screens
**[[Flashcard module: By User Summary|By User Summary]]
**[[Flashcard module: By Card Summary|By Card Summary]]
*[[Flashcard module: Edit Screen|Edit Screen]]

== See also ==
* [[Lesson_module#The_Flash_card_lesson|Flash card presentation]] in the [[Lesson module]] is an alternative to this module.
* Using Moodle [http://moodle.org/mod/forum/view.php?id=7180 Flashcard module forum]
* [[http://docs.activeprolearn.com/en/doku.php?id=:mod:flashcard|Complete documentation in English]]

[[Category:Contributed code]]
[[Category:Medicine]]

[[fr: Flashcard]]
[[es:Módulo flashcard]]

WikipediaCalls filter

2013-03-30T00:28:44Z

Vf: Created page with "This plugin is documented in the [https://docs.moodle.org/22/en/WikipediaCalls_filter| Moodle 2.2 documentation]"

This plugin is documented in the [https://docs.moodle.org/22/en/WikipediaCalls_filter| Moodle 2.2 documentation]

File:import export controls.jpg

2012-11-04T14:40:16Z

Vf:

File:importing config.jpg

2012-11-04T14:39:57Z

Vf:

Dashboard Configuration: Exporting/Importing Configuration

2012-11-04T14:39:41Z

Vf: Created page with " back to index Once you have fully configured a dasboard element and have prooven it works good, you may export and store into your local file system a conf..."

[[Dashboard Block | back to index]]

Once you have fully configured a dasboard element and have prooven it works good, you may export and store into your local file system a configuration snapshot of this bloc settings.

===Exporting===

1. Go back to the configuration panel and find the import/export controls:

[[Image:import_export_controls.jpg]]

2. Click on the "Get the current config" config link

3. You will proposed to store the snapshot on your local computer.

===Importing===

1. Go back to the configuration panel and find the import/export controls:

2. Click on the "import config" link, you will get a texte area where to paste the configuration string:

[[Image:importing_config.jpg]]

3. Paste the config and hit "Save changes" button.

Dashboard Block

2012-11-04T14:32:28Z

Vf: /* Exporting/importing the Block Configuration */

The "Dashboard Block" (more accurately Dashboard Element Block) allows displaying graphically or litterally the result of any query made in Moodle.

When used in standard course formats, the block gives access to an extra page displaying the data redering for the specified query.

When used in a paged format such as Flexipage, or any format allowing blocks to layout freely over the page, the block may display directly the graph rendering and be combined to other blocks to fgorm a complex, highly customizable dashboard.

This blocks uses state-of-the art GPL libraries such as MIT JQplot and some other integrations. It has provision for powerfull data filtering and for using results for automatically generated exports.

==Installation==

The block is standalone and provided with own graphic libraries. Just proceed to standard install by copying the code into the /blocks directory of Moodle and browsing to the notification page to get it installed logically.

Provided libraries are :

JQplot : MIT Graph plotting library in HTML5
TimeLine : A smart time line (still to develop)
GoogleMapAPI : A wrapper to google map plotting of geolocated information

==Capabilities and security advice==

This block allows very deep data reading in Moodle database and powerfull data display. As the query can be written by power users with configuraiton capability, the block could be misused by unauthorised people and produce unwanted access to critical information.

To reduce such risks, a couple of capabilities has been added to control precisely :

who is allowed to add such a blcok in a coutse.
who is allowed to access the block configuration.

==Major rendering features==

===Litteral===

*Linear table raw
*Linear table cleaned
*Linear table with subtotals
*Linear table with colour value coding (one column)

* Tabular table Nx1 dimension
* Tree shaped hierarchic developement

===Graphical===

*Bars
*Lines
*Pies
*Donuts
*Timeline (expérimental)
*GoogleMap

===File export generation===

*CSV export (all data)
*CSV export (filtered data)

==Data Filtering==

*Multidimensional filtering
*Blocks filtering binding to the whole page for syncing several blocks to identical filtering values.

==Global behaviour of the block==

The key point of the block is its confguration form that will define all information needed to get data, filter it, choose what should be output in each rendering method, and finally individual parameters for each rendering method.

Additional configuration allows to add dynamic filtering proposed to end users to filter dynamically the output.

Althoug the setup form and rules are quite complex, we tried to implement a very lot of possibilities so this bloc becomes some kind of "swiss-knife" for Moodle smart reporting.

==Global Settings==

Some global settings allow derivated operation, such as querying an external (PostGre) database, or changing some technical performance features.

[[Dashboard Block Global Settings | Global Settings]]

==Instance Configuration==

The configuration documentation is splitted into sections, each addressing a key feature of the dashboard.

* [[Dashboard Configuration: Rendering location | Configuration: Rendering location]]
* [[Dashboard Configuration: Rendering channels | Configuration: Rendering channels]]
* [[Dashboard Configuration: Writing Query | Configuration: Writing Query]]
* [[Dashboard Configuration: Raw data (litteral) rendering | Configuration: Raw data (litteral) rendering]]
* [[Dashboard Configuration: Graph rendering settings | Configuration: Graph rendering settings]]
* [[Dashboard Configuration: Configuring summarizers | Configuration: Configuring summarizers]]
* [[Dashboard Configuration: Cache options and setting up exports | Configuration: Cache options and setting up exports]]

Some extra configuration can improve data display

* [[Dashboard Configuration: Additional settings for crosstable and tree-shaped display | Additional settings for crosstable and tree-shaped data display]]
* [[Dashboard Configuration: Additional parameters for output colouring of data | Additional parameters for output colouring of data]]
* [[Dashboard Configuration: Plotting geographic information | Additional parameters for geographic plotting (experimental)]]
* [[Dashboard Configuration: Special Features on Columns for Output | Additional special settings when choosing output columns]]

==Tips==

===Exporting/importing the Block Configuration===

This tip is usefull as the configuration of this bloc is huge and uses a lot of variables. The configuration export/import utility allows you to export an encoded configuration string as a text file, store it to your local system, then import it again in, say, a new unconfigured block instance. Configuraiton export contains all the dashboard configuration including the whole query, so it is easy to make several dashboard elements as a variant from a stored one.

* [[Dashboard Configuration: Exporting/Importing Configuration | How to export/import configuration]]

==Development Road Map==

These are future features that are foreseen in the next road map for Dashboard Block.

* Query parametrization with user filled variables
* PDF generators
* Crosstable Excel exports
* Filtering values pre-fetch caching to improve performance
* Accessory database extension to MySQL schemes

=== Reference, information, development and support ===

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

[[fr:Bloc Tableau de bord]]

Dashboard Block

2012-11-04T14:31:16Z

Vf: /* Instance Configuration */

The "Dashboard Block" (more accurately Dashboard Element Block) allows displaying graphically or litterally the result of any query made in Moodle.

When used in standard course formats, the block gives access to an extra page displaying the data redering for the specified query.

When used in a paged format such as Flexipage, or any format allowing blocks to layout freely over the page, the block may display directly the graph rendering and be combined to other blocks to fgorm a complex, highly customizable dashboard.

This blocks uses state-of-the art GPL libraries such as MIT JQplot and some other integrations. It has provision for powerfull data filtering and for using results for automatically generated exports.

==Installation==

The block is standalone and provided with own graphic libraries. Just proceed to standard install by copying the code into the /blocks directory of Moodle and browsing to the notification page to get it installed logically.

Provided libraries are :

JQplot : MIT Graph plotting library in HTML5
TimeLine : A smart time line (still to develop)
GoogleMapAPI : A wrapper to google map plotting of geolocated information

==Capabilities and security advice==

This block allows very deep data reading in Moodle database and powerfull data display. As the query can be written by power users with configuraiton capability, the block could be misused by unauthorised people and produce unwanted access to critical information.

To reduce such risks, a couple of capabilities has been added to control precisely :

who is allowed to add such a blcok in a coutse.
who is allowed to access the block configuration.

==Major rendering features==

===Litteral===

*Linear table raw
*Linear table cleaned
*Linear table with subtotals
*Linear table with colour value coding (one column)

* Tabular table Nx1 dimension
* Tree shaped hierarchic developement

===Graphical===

*Bars
*Lines
*Pies
*Donuts
*Timeline (expérimental)
*GoogleMap

===File export generation===

*CSV export (all data)
*CSV export (filtered data)

==Data Filtering==

*Multidimensional filtering
*Blocks filtering binding to the whole page for syncing several blocks to identical filtering values.

==Global behaviour of the block==

The key point of the block is its confguration form that will define all information needed to get data, filter it, choose what should be output in each rendering method, and finally individual parameters for each rendering method.

Additional configuration allows to add dynamic filtering proposed to end users to filter dynamically the output.

Althoug the setup form and rules are quite complex, we tried to implement a very lot of possibilities so this bloc becomes some kind of "swiss-knife" for Moodle smart reporting.

==Global Settings==

Some global settings allow derivated operation, such as querying an external (PostGre) database, or changing some technical performance features.

[[Dashboard Block Global Settings | Global Settings]]

==Instance Configuration==

The configuration documentation is splitted into sections, each addressing a key feature of the dashboard.

* [[Dashboard Configuration: Rendering location | Configuration: Rendering location]]
* [[Dashboard Configuration: Rendering channels | Configuration: Rendering channels]]
* [[Dashboard Configuration: Writing Query | Configuration: Writing Query]]
* [[Dashboard Configuration: Raw data (litteral) rendering | Configuration: Raw data (litteral) rendering]]
* [[Dashboard Configuration: Graph rendering settings | Configuration: Graph rendering settings]]
* [[Dashboard Configuration: Configuring summarizers | Configuration: Configuring summarizers]]
* [[Dashboard Configuration: Cache options and setting up exports | Configuration: Cache options and setting up exports]]

Some extra configuration can improve data display

* [[Dashboard Configuration: Additional settings for crosstable and tree-shaped display | Additional settings for crosstable and tree-shaped data display]]
* [[Dashboard Configuration: Additional parameters for output colouring of data | Additional parameters for output colouring of data]]
* [[Dashboard Configuration: Plotting geographic information | Additional parameters for geographic plotting (experimental)]]
* [[Dashboard Configuration: Special Features on Columns for Output | Additional special settings when choosing output columns]]

==Tips==

===Exporting/importing the Block Configuration===

This tip is usefull as the configuration of this bloc is huge and uses a lot of variables. The configuration export/import utility allows you to export an encoded configuration string as a text file, store it to your local system, then import it again in, say, a new unconfigured block instance. Configuraiton export contains all the dashboard configuration including the whole query, so it is easy to make several dashboard elements as a variant from a stored one.

==Development Road Map==

These are future features that are foreseen in the next road map for Dashboard Block.

* Query parametrization with user filled variables
* PDF generators
* Crosstable Excel exports
* Filtering values pre-fetch caching to improve performance
* Accessory database extension to MySQL schemes

=== Reference, information, development and support ===

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

[[fr:Bloc Tableau de bord]]

File:summarizer settings.jpg

2012-11-04T14:26:56Z

Vf:

Dashboard Configuration: Configuring summarizers

2012-11-04T14:26:32Z

Vf: Created page with " Back to index Summarizers are automatic sums that will aggregate values in the output. They are printed at bottom of the block, below the ouptut tables or..."

[[Dashboard Block | Back to index]]

Summarizers are automatic sums that will aggregate values in the output.

They are printed at bottom of the block, below the ouptut tables or plotted graphs.

[[Image:summarizer_settings.jpg]]

===Summarizers===

One or more summarizers can be defined using the aliases columns. This field can hold a semi-column separated list
of output column names. Note that summarizers are only consistant with numeric aggregable data. Examples of non relvant
information are :

* Text fields
* Pre-aggregated information (such as means)

===Sums formatting===

Alike many output descriptors, the final result of the sums can be post-formatted on base of the sprintf() function syntax.
There should be here one formatting formula per defined column in a semi-column separated list. As usual, empty strings
stands for unformatted raw output.

===Sums Labels===

To give end user consistency of the summarizer semantic, explicit labels can be used for display, rather technical column aliases.
You mya define here a semi-column spaated list of summarizer visible names, one per defined summarizer.

Dashboard Configuration: Special Features on Columns for Output

2012-11-04T12:27:07Z

Vf:

[[Dashboard Block | Back to index]]

===Special features on data output : Summating output===

When a column name of the output is mentionned as

S(''column_name'')

output values will be accumulated in order of the display.

Dashboard Configuration: Special Features on Columns for Output

2012-11-04T12:26:54Z

Vf: Created page with " Back to index ===Special features on data output : Summating output=== When a column name of the output is mentionned as S(''column_name'') output va..."

[[Dashboard block | Back to index]]

===Special features on data output : Summating output===

When a column name of the output is mentionned as

S(''column_name'')

output values will be accumulated in order of the display.

Dashboard Block

2012-11-04T12:25:02Z

Vf: /* Instance Configuration */

The "Dashboard Block" (more accurately Dashboard Element Block) allows displaying graphically or litterally the result of any query made in Moodle.

When used in standard course formats, the block gives access to an extra page displaying the data redering for the specified query.

When used in a paged format such as Flexipage, or any format allowing blocks to layout freely over the page, the block may display directly the graph rendering and be combined to other blocks to fgorm a complex, highly customizable dashboard.

This blocks uses state-of-the art GPL libraries such as MIT JQplot and some other integrations. It has provision for powerfull data filtering and for using results for automatically generated exports.

==Installation==

The block is standalone and provided with own graphic libraries. Just proceed to standard install by copying the code into the /blocks directory of Moodle and browsing to the notification page to get it installed logically.

Provided libraries are :

JQplot : MIT Graph plotting library in HTML5
TimeLine : A smart time line (still to develop)
GoogleMapAPI : A wrapper to google map plotting of geolocated information

==Capabilities and security advice==

This block allows very deep data reading in Moodle database and powerfull data display. As the query can be written by power users with configuraiton capability, the block could be misused by unauthorised people and produce unwanted access to critical information.

To reduce such risks, a couple of capabilities has been added to control precisely :

who is allowed to add such a blcok in a coutse.
who is allowed to access the block configuration.

==Major rendering features==

===Litteral===

*Linear table raw
*Linear table cleaned
*Linear table with subtotals
*Linear table with colour value coding (one column)

* Tabular table Nx1 dimension
* Tree shaped hierarchic developement

===Graphical===

*Bars
*Lines
*Pies
*Donuts
*Timeline (expérimental)
*GoogleMap

===File export generation===

*CSV export (all data)
*CSV export (filtered data)

==Data Filtering==

*Multidimensional filtering
*Blocks filtering binding to the whole page for syncing several blocks to identical filtering values.

==Global behaviour of the block==

The key point of the block is its confguration form that will define all information needed to get data, filter it, choose what should be output in each rendering method, and finally individual parameters for each rendering method.

Additional configuration allows to add dynamic filtering proposed to end users to filter dynamically the output.

Althoug the setup form and rules are quite complex, we tried to implement a very lot of possibilities so this bloc becomes some kind of "swiss-knife" for Moodle smart reporting.

==Global Settings==

Some global settings allow derivated operation, such as querying an external (PostGre) database, or changing some technical performance features.

[[Dashboard Block Global Settings | Global Settings]]

==Instance Configuration==

The configuration documentation is splitted into sections, each addressing a key feature of the dashboard.

* [[Dashboard Configuration: Rendering location | Configuration: Rendering location]]
* [[Dashboard Configuration: Rendering channels | Configuration: Rendering channels]]
* [[Dashboard Configuration: Writing Query | Configuration: Writing Query]]
* [[Dashboard Configuration: Raw data (litteral) rendering | Configuration: Raw data (litteral) rendering]]
* [[Dashboard Configuration: Graph rendering settings | Configuration: Graph rendering settings]]
* [[Dashboard Configuration: Configuring summarizers | Configuration: Configuring summarizers]]
* [[Dashboard Configuration: Cache options and setting up exports | Configuration: Cache options and setting up exports]]

Some extra configuration can improve data display

* [[Dashboard Configuration: Additional settings for crosstable and tree-shaped display | Additional settings for crosstable and tree-shaped data display]]
* [[Dashboard Configuration: Additional parameters for output colouring of data | Additional parameters for output colouring of data]]
* [[Dashboard Configuration: Plotting geographic information | Additional parameters for geographic plotting (experimental)]]
* [[Dashboard Configuration: Special Features on Columns for Output | Additional special settings when choosing output columns]]

==Development Road Map==

These are future features that are foreseen in the next road map for Dashboard Block.

* Query parametrization with user filled variables
* PDF generators
* Crosstable Excel exports
* Filtering values pre-fetch caching to improve performance
* Accessory database extension to MySQL schemes

=== Reference, information, development and support ===

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

[[fr:Bloc Tableau de bord]]

Dashboard Configuration: Plotting geographic information

2012-11-04T12:20:16Z

Vf:

[[Dashboard Block | back to index]]

Geographic data settings

Geolocated information are plotted on map as graphical markers. Markers can be defined as:

A quadruplet: Title, Latitude, Longitude, Marker Class
A sextuplet: Title, Address, Post code, City, Region Code, Marker Class

Information fields have following specification:

Title: Textual label of the marker
Latitude: floating point latitude
Longitude: floating point longitude
Address: road information
Post code: Official post or zip code
City: City name
Marker Class: A classname, that will bind to a graphical icon

Setting fields let you bind required information to request output fields. Setting outputs will usually accept one or more field (or alias) names separated by semicolons (";").

Title input: Query output fieldname providing the textual label
Location input:
Case 1: THE output column name providing the geolocation couple as a comma pair of floating point values : "lat,lng" (ex : 47.098456,1.4534456)
Case 2: A semicolon separated list of query output fieldnames (or aliases) that provide in order : address, post code, city, and region code (*)
Marker type input: The query output fieldname that provides a class label

(*) Some constant values can be given for city, post code and region code, using quoted values in place of field name:

address;cp;city;"GB"

will always provide the value "GB" as region code.

Dashboard Configuration: Plotting geographic information

2012-11-04T12:19:11Z

Vf: Created page with " back to index Geographic data settings Geolocated information are plotted on map as graphical markers. Markers can be defined as: A quadruplet: Titl..."

[[Dashboard Blocks | back to index]]

Geographic data settings

Geolocated information are plotted on map as graphical markers. Markers can be defined as:

A quadruplet: Title, Latitude, Longitude, Marker Class
A sextuplet: Title, Address, Post code, City, Region Code, Marker Class

Information fields have following specification:

Title: Textual label of the marker
Latitude: floating point latitude
Longitude: floating point longitude
Address: road information
Post code: Official post or zip code
City: City name
Marker Class: A classname, that will bind to a graphical icon

Setting fields let you bind required information to request output fields. Setting outputs will usually accept one or more field (or alias) names separated by semicolons (";").

Title input: Query output fieldname providing the textual label
Location input:
Case 1: THE output column name providing the geolocation couple as a comma pair of floating point values : "lat,lng" (ex : 47.098456,1.4534456)
Case 2: A semicolon separated list of query output fieldnames (or aliases) that provide in order : address, post code, city, and region code (*)
Marker type input: The query output fieldname that provides a class label

(*) Some constant values can be given for city, post code and region code, using quoted values in place of field name:

address;cp;city;"GB"

will always provide the value "GB" as region code.

Dashboard Block

2012-11-04T12:18:47Z

Vf: /* Instance Configuration */

The "Dashboard Block" (more accurately Dashboard Element Block) allows displaying graphically or litterally the result of any query made in Moodle.

When used in standard course formats, the block gives access to an extra page displaying the data redering for the specified query.

When used in a paged format such as Flexipage, or any format allowing blocks to layout freely over the page, the block may display directly the graph rendering and be combined to other blocks to fgorm a complex, highly customizable dashboard.

This blocks uses state-of-the art GPL libraries such as MIT JQplot and some other integrations. It has provision for powerfull data filtering and for using results for automatically generated exports.

==Installation==

The block is standalone and provided with own graphic libraries. Just proceed to standard install by copying the code into the /blocks directory of Moodle and browsing to the notification page to get it installed logically.

Provided libraries are :

JQplot : MIT Graph plotting library in HTML5
TimeLine : A smart time line (still to develop)
GoogleMapAPI : A wrapper to google map plotting of geolocated information

==Capabilities and security advice==

This block allows very deep data reading in Moodle database and powerfull data display. As the query can be written by power users with configuraiton capability, the block could be misused by unauthorised people and produce unwanted access to critical information.

To reduce such risks, a couple of capabilities has been added to control precisely :

who is allowed to add such a blcok in a coutse.
who is allowed to access the block configuration.

==Major rendering features==

===Litteral===

*Linear table raw
*Linear table cleaned
*Linear table with subtotals
*Linear table with colour value coding (one column)

* Tabular table Nx1 dimension
* Tree shaped hierarchic developement

===Graphical===

*Bars
*Lines
*Pies
*Donuts
*Timeline (expérimental)
*GoogleMap

===File export generation===

*CSV export (all data)
*CSV export (filtered data)

==Data Filtering==

*Multidimensional filtering
*Blocks filtering binding to the whole page for syncing several blocks to identical filtering values.

==Global behaviour of the block==

The key point of the block is its confguration form that will define all information needed to get data, filter it, choose what should be output in each rendering method, and finally individual parameters for each rendering method.

Additional configuration allows to add dynamic filtering proposed to end users to filter dynamically the output.

Althoug the setup form and rules are quite complex, we tried to implement a very lot of possibilities so this bloc becomes some kind of "swiss-knife" for Moodle smart reporting.

==Global Settings==

Some global settings allow derivated operation, such as querying an external (PostGre) database, or changing some technical performance features.

[[Dashboard Block Global Settings | Global Settings]]

==Instance Configuration==

The configuration documentation is splitted into sections, each addressing a key feature of the dashboard.

* [[Dashboard Configuration: Rendering location | Configuration: Rendering location]]
* [[Dashboard Configuration: Rendering channels | Configuration: Rendering channels]]
* [[Dashboard Configuration: Writing Query | Configuration: Writing Query]]
* [[Dashboard Configuration: Raw data (litteral) rendering | Configuration: Raw data (litteral) rendering]]
* [[Dashboard Configuration: Graph rendering settings | Configuration: Graph rendering settings]]
* [[Dashboard Configuration: Configuring summarizers | Configuration: Configuring summarizers]]
* [[Dashboard Configuration: Cache options and setting up exports | Configuration: Cache options and setting up exports]]

Some extra confguration can improve data display

* [[Dashboard Configuration: Additional settings for crosstable and tree-shaped display | Additional settings for crosstable and tree-shaped data display]]
* [[Dashboard Configuration: Additional parameters for output colouring of data | Additional parameters for output colouring of data]]
* [[Dashboard Configuration: Plotting geographic information | Additional parameters for geographic plotting (experimental)]]

==Development Road Map==

These are future features that are foreseen in the next road map for Dashboard Block.

* Query parametrization with user filled variables
* PDF generators
* Crosstable Excel exports
* Filtering values pre-fetch caching to improve performance
* Accessory database extension to MySQL schemes

=== Reference, information, development and support ===

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

[[fr:Bloc Tableau de bord]]

Dashboard Configuraton: Plotting geographic information

2012-11-04T12:17:37Z

Vf: /* Geographic data settings */

[[Dashboard block | Back to index]]

==Geographic data settings==

Geolocated information are plotted on map as graphical markers. Markers can be defined as:

* A quadruplet: Title, Latitude, Longitude, Marker Class
* A sextuplet: Title, Address, Post code, City, Region Code, Marker Class

Information fields have following specification:

* ''Title'': Textual label of the marker
* ''Latitude'': floating point latitude
* ''Longitude'': floating point longitude
* ''Address'': road information
* ''Post code'': Official post or zip code
* ''City'': City name
* ''Marker Class'': A classname, that will bind to a graphical icon

Setting fields let you bind required information to request output fields. Setting outputs will usually accept one or more field (or alias) names separated by semicolons (";").

* ''Title input'': Query output fieldname providing the textual label
* ''Location input'':
** Case 1: THE output column name providing the geolocation couple as a comma pair of floating point values : "lat,lng" (ex : 47.098456,1.4534456)
** Case 2: A semicolon separated list of query output fieldnames (or aliases) that provide in order : address, post code, city, and region code (*)
* ''Marker type input'': The query output fieldname that provides a class label

(*) Some constant values can be given for city, post code and region code, using quoted values in place of field name:

address;cp;city;"GB"

will always provide the value "GB" as region code.

Dashboard Configuraton: Plotting geographic information

2012-11-04T12:17:20Z

Vf: Created page with " Back to index ==Geographic data settings== Geolocated information are plotted on map as graphical markers. Markers can be defined as: * A quadruplet: Tit..."

Dashboard Block

2012-11-04T12:13:53Z

Vf: /* Instance Configuration */

The "Dashboard Block" (more accurately Dashboard Element Block) allows displaying graphically or litterally the result of any query made in Moodle.

When used in standard course formats, the block gives access to an extra page displaying the data redering for the specified query.

When used in a paged format such as Flexipage, or any format allowing blocks to layout freely over the page, the block may display directly the graph rendering and be combined to other blocks to fgorm a complex, highly customizable dashboard.

This blocks uses state-of-the art GPL libraries such as MIT JQplot and some other integrations. It has provision for powerfull data filtering and for using results for automatically generated exports.

==Installation==

The block is standalone and provided with own graphic libraries. Just proceed to standard install by copying the code into the /blocks directory of Moodle and browsing to the notification page to get it installed logically.

Provided libraries are :

JQplot : MIT Graph plotting library in HTML5
TimeLine : A smart time line (still to develop)
GoogleMapAPI : A wrapper to google map plotting of geolocated information

==Capabilities and security advice==

This block allows very deep data reading in Moodle database and powerfull data display. As the query can be written by power users with configuraiton capability, the block could be misused by unauthorised people and produce unwanted access to critical information.

To reduce such risks, a couple of capabilities has been added to control precisely :

who is allowed to add such a blcok in a coutse.
who is allowed to access the block configuration.

==Major rendering features==

===Litteral===

*Linear table raw
*Linear table cleaned
*Linear table with subtotals
*Linear table with colour value coding (one column)

* Tabular table Nx1 dimension
* Tree shaped hierarchic developement

===Graphical===

*Bars
*Lines
*Pies
*Donuts
*Timeline (expérimental)
*GoogleMap

===File export generation===

*CSV export (all data)
*CSV export (filtered data)

==Data Filtering==

*Multidimensional filtering
*Blocks filtering binding to the whole page for syncing several blocks to identical filtering values.

==Global behaviour of the block==

The key point of the block is its confguration form that will define all information needed to get data, filter it, choose what should be output in each rendering method, and finally individual parameters for each rendering method.

Additional configuration allows to add dynamic filtering proposed to end users to filter dynamically the output.

Althoug the setup form and rules are quite complex, we tried to implement a very lot of possibilities so this bloc becomes some kind of "swiss-knife" for Moodle smart reporting.

==Global Settings==

Some global settings allow derivated operation, such as querying an external (PostGre) database, or changing some technical performance features.

[[Dashboard Block Global Settings | Global Settings]]

==Instance Configuration==

The configuration documentation is splitted into sections, each addressing a key feature of the dashboard.

* [[Dashboard Configuration: Rendering location | Configuration: Rendering location]]
* [[Dashboard Configuration: Rendering channels | Configuration: Rendering channels]]
* [[Dashboard Configuration: Writing Query | Configuration: Writing Query]]
* [[Dashboard Configuration: Raw data (litteral) rendering | Configuration: Raw data (litteral) rendering]]
* [[Dashboard Configuration: Graph rendering settings | Configuration: Graph rendering settings]]
* [[Dashboard Configuration: Configuring summarizers | Configuration: Configuring summarizers]]
* [[Dashboard Configuration: Cache options and setting up exports | Configuration: Cache options and setting up exports]]

Some extra confguration can improve data display

* [[Dashboard Configuration: Additional settings for crosstable and tree-shaped display | Additional settings for crosstable and tree-shaped data display]]
* [[Dashboard Configuration: Additional parameters for output colouring of data | Additional parameters for output colouring of data]]
* [[Dashboard Configuraton: Plotting geographic information | Additional parameters for geographic plotting (experimental)]]

==Development Road Map==

These are future features that are foreseen in the next road map for Dashboard Block.

* Query parametrization with user filled variables
* PDF generators
* Crosstable Excel exports
* Filtering values pre-fetch caching to improve performance
* Accessory database extension to MySQL schemes

=== Reference, information, development and support ===

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

[[fr:Bloc Tableau de bord]]

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T12:06:43Z

Vf: /* Filter Options */

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatting data directly in the SQL syntax may not be friendly for SQL readability. This setting defines some post-formatting filters you can apply on data, based on the sprintf() syntax. Using formatting codes of sprintf makes data reformatting easy, f.e. for numeric output:

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This checkbox disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : Outputting results in files will require the cache is enabled.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

Filtering will generate additional SQL WHERE clauses that need to be explicitely located in the initial query:

You will use a <%%FILTERS%%> placeholder for this:

SELECT
firstname as fn,
lastname as ln,
city as ct
FROM
mdl_user
<%%FILTERS%%>

Filters stakeholder will in this case add the whole WHERE clause. In case your query already has WHERE statements, the flters stakeholder will only add additional filtering tests:

SELECT
firstname as fn,
lastname as ln,
city as ct
FROM
mdl_user
WHERE
country = 'AU'
<%%FILTERS%%>

The above sample prefilters users from Australia, than adds what is required by filters.

What follows is NOT a valid lcoation:

SELECT
data1,data2
FROM
table1 t1,
table2 t2
GROUP BY
data2
<%%FILTERS%%>
ORDER BY
data1

As a WHERE clause cannot be run after a GROUP BY.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter definition needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

===Using multiple filters===

Beware : when using two or more filters, each of them provides its modality list independently. Thus some filtering combination could result in possible "no values" ar all.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Original query for the sample)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T12:04:54Z

Vf: /* Output Dynamic Filters */

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatting data directly in the SQL syntax may not be friendly for SQL readability. This setting defines some post-formatting filters you can apply on data, based on the sprintf() syntax. Using formatting codes of sprintf makes data reformatting easy, f.e. for numeric output:

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This checkbox disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : Outputting results in files will require the cache is enabled.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

Filtering will generate additional SQL WHERE clauses that need to be explicitely located in the initial query:

You will use a <%%FILTERS%%> placeholder for this:

SELECT
firstname as fn,
lastname as ln,
city as ct
FROM
mdl_user
<%%FILTERS%%>

Filters stakeholder will in this case add the whole WHERE clause. In case your query already has WHERE statements, the flters stakeholder will only add additional filtering tests:

SELECT
firstname as fn,
lastname as ln,
city as ct
FROM
mdl_user
WHERE
country = 'AU'
<%%FILTERS%%>

The above sample prefilters users from Australia, than adds what is required by filters.

What follows is NOT a valid lcoation:

SELECT
data1,data2
FROM
table1 t1,
table2 t2
GROUP BY
data2
<%%FILTERS%%>
ORDER BY
data1

As a WHERE clause cannot be run after a GROUP BY.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter definition needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Original query for the sample)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T12:02:05Z

Vf: /* Output Dynamic Filters */

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatting data directly in the SQL syntax may not be friendly for SQL readability. This setting defines some post-formatting filters you can apply on data, based on the sprintf() syntax. Using formatting codes of sprintf makes data reformatting easy, f.e. for numeric output:

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This checkbox disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : Outputting results in files will require the cache is enabled.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

Filtering will generate additional SQL WHERE clauses that need to be explicitely located in the initial query:

You will use a <%%FILTERS%%> placeholder for this:

SELECT
firstname as fn,
lastname as ln,
city as ct
FROM
mdl_user
<%%FILTERS%%>

Filters stakeholder will in this case add the whole WHERE clause. In case your query already has WHERE statements, the flters stakeholder will only add additional filtering tests:

SELECT
firstname as fn,
lastname as ln,
city as ct
FROM
mdl_user
WHERE
country = 'AU'
<%%FILTERS%%>

The above sample prefilters users from Australia, than adds what is required by filters.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter definition needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Original query for the sample)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T11:56:47Z

Vf: /* Filters */

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatting data directly in the SQL syntax may not be friendly for SQL readability. This setting defines some post-formatting filters you can apply on data, based on the sprintf() syntax. Using formatting codes of sprintf makes data reformatting easy, f.e. for numeric output:

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This checkbox disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : Outputting results in files will require the cache is enabled.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter definition needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Original query for the sample)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T11:54:36Z

Vf: /* Override Big Results security */

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatting data directly in the SQL syntax may not be friendly for SQL readability. This setting defines some post-formatting filters you can apply on data, based on the sprintf() syntax. Using formatting codes of sprintf makes data reformatting easy, f.e. for numeric output:

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This checkbox disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : Outputting results in files will require the cache is enabled.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter defintion needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Original query for the sample)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T11:54:19Z

Vf:

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatting data directly in the SQL syntax may not be friendly for SQL readability. This setting defines some post-formatting filters you can apply on data, based on the sprintf() syntax. Using formatting codes of sprintf makes data reformatting easy, f.e. for numeric output:

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This check box disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : Outputting results in files will require the cache is enabled.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter defintion needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Original query for the sample)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Dashboard Configuration: Raw data (litteral) rendering

2012-11-04T11:45:12Z

Vf: /* Table type */

[[Dashboard Block | Back to index]]

Raw litteral output uses direct data from query output and display those data in textual tables.

Depending on configuration settings, several display modes are possible. Some modes will need additional settings provided in accessory form sections.

==Common settings for row data output==

===Choosing columns as data output===

The first absolute choice to execute is selecting which colun from query are to be displayed in table. Often the raw data will only display a part of the effective resulting dataset. You will select column in order by writing here a semi-column separated list of aliases. Of course aliases names should be present in the query!

example :

Say we enter such a query:

SELECT
firstname as fn,
lastname as ln,
username as login
...

Following names could figure in the column selection textfield: ln;fn;login

===Output fields display name===

Aliased token are seldom friendly names for end-users. The texfield for column names allows to convert column identities to friendly names in effective display. Just separate dispalyed names by semi-column (;) and enter same number of names for each declaed column, in same order.

With previous example, we could have setup:

Output fields : fn;ln;login
Output field names : Firstname;Lastname;UserID

===Output fields format===

Formatter les données exactement dans l'expression de la requête SQL n'est pas toujours commode. Cette liste permet d'effectuer un post-formattage des données, basé sur la fonction sprintf(). Il est par exemple possible de reformatter des données numériques en utilisant les codes de format de cette fonction :

%s : string
%d : integer (floored)
%03d : integer with 3 digits, 0-filled (001, 002, etc.)
%.2f : 2 digit decimals
etc. (check the PHP sprintf documentation for the complete formatting syntax).

==Result Page Size==

This setting sets up a page limitation for linear tables as output.

===Override Big Results security===

This check box disables for this block instance the "Big Result" security setting (global configuration) that forces data paging for big results. This is usefull for graphed output displaying a lot of data.

==Query caching==

===Enabling query cache===

When query cache is enabled, the Dashboard Block saves in a cache the query results and willuse this data during the TTL.

===TTL (Time to live)===

TTL is setup in minutes. Caching is effective when enabled AND a TTL is set higher than 0.

Note : L'activation du cache de résultat est obligatoire pour activer les exports en fichiers.

==Data Cleanup (linear table output only)==

If data cleaning is enabled, cells containing same value than a superior cell will remain undisplayed, for better viewing confort.

==Sortable Table (linear table only)==

If table is set to sortable, column names will enable sorting links.

==Sub-totals==

If some summarizers are setup (See "summarizers"), than subtotals on the specified summarizers can be obtained on value change of a given column. Having the subtotals shown in output assumes also that table '''is sorted using the subtotal''' driving column.

==Output Dynamic Filters==

This important setting chapter tells how to configure dynamic filter the end user will use to select what part of the resuting dataset will be displayed.

Filters are criteria definitions that will add "selectors" (select lists) above the output redenring. A filter usually is matching a single column of the initial query. All disticnt values in this column fromthe original result are used as filtering set.

Example :

Let's take q query:

SELECT
firstname as fn,
lastname as ln,
city as ct

....

and users living in PARIS, SANTA CLARA (CA) and PRAGUE.

If a filter "city as ct" is mentionned as filter, a select will be added to the display choosing in the set: "*,PARIS,SANTA CLARA,PRAGUE". '*' stands for "unfiltered". Choosing any value at display time will only keep correponding data.

===Filters===

Filter will be defined as a semi-column (;) separated list of SQL columns definitions.

Filter defintion needs the entire SQL field clause including alias. Thus in above example the correct expressionis "city as ct" and not "city" or "ct".

===Filter names===

Right as for output columns, filter criterias will have comprehensive labels for display.

You may enter a semi-column (;) separated list of labels for naming each filter, in same order and amount than the filter definition list.

Note : There is no provision for escaping litteral ";". Thus no semi-column should be used in names or labels...

===Filter Defaults===

Filter add some clauses in final WHERE statement. Without any default value, filtering is disabled when Dashboard element is show for the first time in the browsing session. This setting allows to force chossing a value for filtering by default. Possible choice is:

*FIRST: Chooses first filtering value found in filtering set
*LAST: Chooses last filtering value found in filtering set
*<empty>: No default value, using '*'.

All defaults will be set as a semi-column(;) separated list,in same order and amount than filter declarations.

Example :

Filter : department as dpt;city as ct
Filter defaults: ;FIRST

In this example, the default for department is '*'(unfiltered)

===Filter Options===

Some options can drastically change the behaviour of the filter or affect several Dashboard Elements on a same page layout. This options are "single-letter markers" that can appear in any order:

*g : Enables global filtering. If other filter from other Dashboard Elements are using the same column definition on the page, than changing a filter value in one Dashboard will attempt to affect all other identical global filters.
*s : Force "Single" : When present, this will avoid to provide the "*" (unfiltered) option in fitler value set, and will force to choose a filtering value as default. This is usefull for "Big Size Results" that would not be worth trying to display in fill range. If no explicit setting for "Filter défaut" has been specified, then FIRST is forced.
*m : Allow "Multiple" : When present, this markr will allow choosing multiple valuesin filter value set, thus allowing to define ranges, or subsets. Filter select turns to multiple selection widget.
*x : "Crossover" : Usually, filtering data adds additional clauses that may need complex query cleanup and processing. In some cases, those cleanup operations may fail to produce syntax safe query, (when using with unions, subqueries, multiple nested clauses ORDER BY, etc.). This marker will disable these cleanup operations, that may in certain cases, save some situations.

==Table type==

Raw data may be displayed using several table layout, depending on data organisation:

*'''Linear display:''' Data are displayed as a simple table, each record as a line, developping output fields as cells.

[[Image:lineartablesample.jpg]]

(Requête origine pour l'exemple)

*'''Tabular crosstable:''' Data is layout in 2 dimensions as a matrix crosstable. Some extra paramters are needed to control this output mode.

[[Image:matrixsample.jpg]]

*'''Tree-shaped display:''' This mode is dependaing on some contraint on query itself. To use this mode, extracted data must have a hierarchical underlying organisation. Such an organisation would provide:
**A principle of filiation (a record has a parent mapped by an id)
**A node identity (a node can be identified by a value as node name)
**A node value (or serie of value) for each node in the tree.

[[Image:hierarchicsample.jpg]]

This mode needs additional parameters to be set.

Magtest module

2012-11-04T11:14:58Z

Vf:

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs, or even Multitrack test) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Install==

Installs as a standard activtiy plugin by unpacking the module in 'mod' directory and run notifications.

==Setup==

The setup properties are as defined in the [[Magtest module:setup | setup form]]

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants
* mod/magtest/addinstance : People having this capability can add an instance in the course (standard capability)

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T19:29:31Z

Vf: /* Setup */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Install==

Installs as a standard activtiy plugin by unpacking the module in 'mod' directory and run notifications.

==Setup==

The setup properties are as defined in the [[Magtest module:setup | setup form]]

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants
* mod/magtest/addinstance : People having this capability can add an instance in the course (standard capability)

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module:setup

2012-11-03T19:28:36Z

Vf: /* Result */

[[Magtest module | back to index]]

[[image:setup_form.jpg]]

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Global conclusion text===

Sets up a global feedback that will comment the result grid.

Magtest module:setup

2012-11-03T19:28:07Z

Vf:

[[Magtest module | back to index]]

[[image:setup_form.jpg]]

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

Magtest module

2012-11-03T19:27:54Z

Vf: /* Setup */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined in the [[Magtest module:setup | setup form]]

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants
* mod/magtest/addinstance : People having this capability can add an instance in the course (standard capability)

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module:setup

2012-11-03T19:27:17Z

Vf:

[[Magtest module | back to index]]

[[image:setup_form.jpg]]

File:setup form.jpg

2012-11-03T19:26:35Z

Vf: Magtest setup screen

Magtest setup screen

Magtest module:setup

2012-11-03T19:23:57Z

Vf: Created page with " back to index image:setup_form"

[[Magtest module | back to index]]

[[image:setup_form]]

Magtest module

2012-11-03T19:23:21Z

Vf: /* Setup */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined in the [[Magtest module:setup | setup form]]

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants
* mod/magtest/addinstance : People having this capability can add an instance in the course (standard capability)

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T19:23:08Z

Vf: /* Setup */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined in the [Magtest module:setup | setup form]

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants
* mod/magtest/addinstance : People having this capability can add an instance in the course (standard capability)

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T19:19:55Z

Vf: /* Capabilities */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined:

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants
* mod/magtest/addinstance : People having this capability can add an instance in the course (standard capability)

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T19:19:19Z

Vf: /* Capabilities */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined:

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

'''Capabilities for students'''

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

'''Capabilities for teachers and power users'''

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants

'''Miscellaneous'''

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T19:19:03Z

Vf: /* Capabilities */

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined:

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

Capabilities for students

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

Capabilities for teachers and power users

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants

Miscellaneous

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T19:18:23Z

Vf:

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined:

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

Capabilities for students

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

Capability for teachers and power users

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants

Miscellaneous

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

== Reference, information, development and support ==

valery.fremaux-AT-gmail.com
[[Category:Contributed code]]

Magtest module

2012-11-03T11:22:19Z

Vf: Created page with "The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant cla..."

The Magtest module (also standing for Magazine test module, as inspired by the Leisure press personality test customs) provides a multitrack scoring test allowing participant classification in categories. It is simple to setup and use.

The Magtest module defines categories of answers, then defines questions and answers for each of the available categories.

The only activity of students is to perform the test chossing one of the proposed answers, and read result profile feedback (highlighted) at the end.

The module settings allow the test to be played once or accept multiple attemprs (by capability). Also answers can be weighted, so adding more or less credits to an output category.

===Making groups in course with magtest===

Enabling the group making feature, the result of the magtest can be converted into group definition in course. Setup allows defining the group name and group description that will be generated from the magtest participants classification.

Note that to avoid misuse of this feature, the coruse MUST have no groups defined to allow groups generation.

==Setup==

The setup properties are as defined:

===Instance name===

Defines the visible name of the instance in the course

===Intro===

ALlows giving a summary of the activity

===Start and end time===

Used to open or close the actiity in a time range.

===Weighted===

When enabled, distinct weights can be attributed to each answer for its attached category. When disabled, the default constant weight is 1.

===Use the "make group" utility===

Enables the group making feature

===Questions per page===

Sets up how many questions are printed on the same page.

===Allow replay===

Global allow replay switch. A user can replay if allow eplay is enabled AND he has capability to play again.

===Result===

Sets up a global feedback that will comment the result grid.

==Screens==

* Test screen
* Preview (teacher)
* Categories (teacher)
* Questions (teacher)
* Results (teacher)
* Stats (teacher)

==Capabilities==

Capabilities for students

* mod/magtest/multipleattempts : People having this capability enabled can replay the test
* mod/magtest/doit : People having this capability can play the test

Capability for teachers and power users

* mod/magtest/manage : People having this capability can edit, add, delete categories and questions
* mod/magtest/viewotherresults : People having this capability can access to results of all participants

Miscellaneous

* mod/magtest/viewgeneralstat : People having this capability can access to global stats

Publishflow Block : Installation

2012-09-28T21:50:30Z

Vf: /* Warning */

[[Course Publishing block (publishflow)|Back to index]]

The blocks/publishflow installs as usual for blocks.

* Get the archive
* Unzip it in the ''blocks'' diretory of Moodle
* Go to Administration notifications to make the logical install of the block.

You will need to make some prepraration before the module can be used in courses.

Note : This module may be used for easy local deployement of a course, but will not really do much more than common restore (unless less steps in restore). Using this block makes sense when configuring a Moodle Network with some publishing model.

==Warning==

A bug described in:

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

forbids correct install of MNET RPC function records for blocks plugins.

Workarounds:

* Apply correction proposed in the Tracker Issue.
* or change manually RPC function xmlrpcpath values in database (table mdl_mnet_rpc) for having "blocks/" as first path component

Publishflow Block : Installation

2012-09-28T21:50:09Z

Vf: /* Warning */

[[Course Publishing block (publishflow)|Back to index]]

The blocks/publishflow installs as usual for blocks.

* Get the archive
* Unzip it in the ''blocks'' diretory of Moodle
* Go to Administration notifications to make the logical install of the block.

You will need to make some prepraration before the module can be used in courses.

Note : This module may be used for easy local deployement of a course, but will not really do much more than common restore (unless less steps in restore). Using this block makes sense when configuring a Moodle Network with some publishing model.

==Warning==

A bug described in:

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

forbids correct install of MNET RPC function records.

Workarounds:

* Apply correction proposed in the Tracker Issue.
* or change manually RPC function xmlrpcpath values in database (table mdl_mnet_rpc) for having "blocks/" as first path component

Publishflow Block : Installation

2012-09-28T21:49:53Z

Vf: /* Warning */

[[Course Publishing block (publishflow)|Back to index]]

The blocks/publishflow installs as usual for blocks.

* Get the archive
* Unzip it in the ''blocks'' diretory of Moodle
* Go to Administration notifications to make the logical install of the block.

You will need to make some prepraration before the module can be used in courses.

Note : This module may be used for easy local deployement of a course, but will not really do much more than common restore (unless less steps in restore). Using this block makes sense when configuring a Moodle Network with some publishing model.

==Warning==

A bug described in:

[[http://tracker.moodle.org/browse/MDL-35677 | MDL-35677]]

forbids correct install of MNET RPC function records.

Workarounds:

* Apply correction proposed in the Tracker Issue.
* or change manually RPC function xmlrpcpath values in database (table mdl_mnet_rpc) for having "blocks/" as first path component

Publishflow Block : Installation

2012-09-28T21:49:21Z

Vf: /* Warning */

[[Course Publishing block (publishflow)|Back to index]]

The blocks/publishflow installs as usual for blocks.

* Get the archive
* Unzip it in the ''blocks'' diretory of Moodle
* Go to Administration notifications to make the logical install of the block.

You will need to make some prepraration before the module can be used in courses.

Note : This module may be used for easy local deployement of a course, but will not really do much more than common restore (unless less steps in restore). Using this block makes sense when configuring a Moodle Network with some publishing model.

==Warning==

A bug described in:

[[http://tracker.moodle.org/browse/MDL-35677]]

forbids correct install of MNET RPC function records.

Workarounds:

* Apply correction proposed in the Tracker Issue.
* or change manually RPC function xmlrpcpath values in database (table mdl_mnet_rpc) for having "blocks/" as first path component

Publishflow Block : Installation

2012-09-28T21:49:05Z

Vf:

[[Course Publishing block (publishflow)|Back to index]]

The blocks/publishflow installs as usual for blocks.

* Get the archive
* Unzip it in the ''blocks'' diretory of Moodle
* Go to Administration notifications to make the logical install of the block.

You will need to make some prepraration before the module can be used in courses.

Note : This module may be used for easy local deployement of a course, but will not really do much more than common restore (unless less steps in restore). Using this block makes sense when configuring a Moodle Network with some publishing model.

==Warning==

A bug described in:

[http://tracker.moodle.org/browse/MDL-35677]

forbids correct install of MNET RPC function records.

Workarounds:

* Apply correction proposed in the Tracker Issue.
* or change manually RPC function xmlrpcpath values in database (table mdl_mnet_rpc) for having "blocks/" as first path component

Publishflow Block : MNET Services

2012-09-28T21:29:49Z

Vf: /* Functions */

Publishflow implements a set of MNET services in order to perform proper across MNET operations.

Here comes the list of MNET XML-RPC functions that are provided by the blocks XML-RPC API.

Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth.

==Service : publishflow==

===Description===

This service is used to hold all RPC related functions for publishflow operations.

===Functions===

'''delivery_get_sessions():''' get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node.

'''delivery_deliver()''': get a course backup from a remote platform. If data transfer is done using local file system, will only give information about the physical location of a course archive.

'''delivery_deploy()''': deploys a course archive where called. This function has to be called remotely from the archive originator that will drive the deployement process (i.e. the deployment IS NOT initiated from the platform you want the course coming in, but where it goes out).

'''delivery_publish()''': similar to the deployment function, but there are some particularities when dealing between a Course Factory and a Course Catalog Moodle instances.

'''publishflow_updateplatforms()''': This function is called by other hosts in a MNET to explore the network and determine which instances are in the MNET neighborhood.

==Other Unregistered XML-RPC Calls==

The following functions entries are XML-RPC functions that were setup for external control of the deployement. They are not registered into MNET services.

Function name: ''publishflow_rpc_deploy''

'''purpose:'''
Asking from an external system to deploy a course somwhere in the network.

'''parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier: The value that identifies the course backup, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the MNET host where to deploy.
*parmsoverride: a structure that can override any value of the Moodle "course" record thus deployed instance can have its name, shortname or starting date changed. OPTIONAL.
*json_response: if true, the response is JSONed for convenience with remote XML-RPC implementation.

Function name: ''publishflow_rpc_close_course''

'''Purpose:'''
Asks a remote node to close a course (regarding the course life-cycle handling by the publishflow block)

'''Parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier : the value that identifies the course to be closed, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the node where the course needs to be closed
*mode: The closing mode (see publishflow Course life-Cycle in Training Nodes)
*json_response: (see above).

==Alternate form of the external RPC calls==

Some external applications (ERPs) do not provide support for shooting RPC calls with separate parameters (OfBiz). the two functions above are also available in a wrapped alternate form :

publishflow_rpc_deploy_wrapped($wrap)
publishflow_rpc_close_course_wrapped($wrap)

the wrap is an associative array grouping all required parameters in to a single parameter data bundle. these functions are given as 'adaptors' for that special situations.

Publishflow Block : MNET Services

2012-09-28T21:29:37Z

Vf: /* Functions */

Publishflow implements a set of MNET services in order to perform proper across MNET operations.

Here comes the list of MNET XML-RPC functions that are provided by the blocks XML-RPC API.

Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth.

==Service : publishflow==

===Description===

This service is used to hold all RPC related functions for publishflow operations.

===Functions===

'''delivery_get_sessions():''' get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node.

==Functions==

'''delivery_deliver()''': get a course backup from a remote platform. If data transfer is done using local file system, will only give information about the physical location of a course archive.

'''delivery_deploy()''': deploys a course archive where called. This function has to be called remotely from the archive originator that will drive the deployement process (i.e. the deployment IS NOT initiated from the platform you want the course coming in, but where it goes out).

'''delivery_publish()''': similar to the deployment function, but there are some particularities when dealing between a Course Factory and a Course Catalog Moodle instances.

'''publishflow_updateplatforms()''': This function is called by other hosts in a MNET to explore the network and determine which instances are in the MNET neighborhood.

==Other Unregistered XML-RPC Calls==

The following functions entries are XML-RPC functions that were setup for external control of the deployement. They are not registered into MNET services.

Function name: ''publishflow_rpc_deploy''

'''purpose:'''
Asking from an external system to deploy a course somwhere in the network.

'''parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier: The value that identifies the course backup, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the MNET host where to deploy.
*parmsoverride: a structure that can override any value of the Moodle "course" record thus deployed instance can have its name, shortname or starting date changed. OPTIONAL.
*json_response: if true, the response is JSONed for convenience with remote XML-RPC implementation.

Function name: ''publishflow_rpc_close_course''

'''Purpose:'''
Asks a remote node to close a course (regarding the course life-cycle handling by the publishflow block)

'''Parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier : the value that identifies the course to be closed, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the node where the course needs to be closed
*mode: The closing mode (see publishflow Course life-Cycle in Training Nodes)
*json_response: (see above).

==Alternate form of the external RPC calls==

Some external applications (ERPs) do not provide support for shooting RPC calls with separate parameters (OfBiz). the two functions above are also available in a wrapped alternate form :

publishflow_rpc_deploy_wrapped($wrap)
publishflow_rpc_close_course_wrapped($wrap)

the wrap is an associative array grouping all required parameters in to a single parameter data bundle. these functions are given as 'adaptors' for that special situations.

Publishflow Block : MNET Services

2012-09-28T21:29:16Z

Vf: /* Service : coursedelivery_admin */

Publishflow implements a set of MNET services in order to perform proper across MNET operations.

Here comes the list of MNET XML-RPC functions that are provided by the blocks XML-RPC API.

Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth.

==Service : publishflow==

===Description===

This service is used to hold all RPC related functions for publishflow operations.

===Functions===

delivery_get_sessions() : get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node.

==Functions==

'''delivery_deliver()''': get a course backup from a remote platform. If data transfer is done using local file system, will only give information about the physical location of a course archive.

'''delivery_deploy()''': deploys a course archive where called. This function has to be called remotely from the archive originator that will drive the deployement process (i.e. the deployment IS NOT initiated from the platform you want the course coming in, but where it goes out).

'''delivery_publish()''': similar to the deployment function, but there are some particularities when dealing between a Course Factory and a Course Catalog Moodle instances.

'''publishflow_updateplatforms()''': This function is called by other hosts in a MNET to explore the network and determine which instances are in the MNET neighborhood.

==Other Unregistered XML-RPC Calls==

The following functions entries are XML-RPC functions that were setup for external control of the deployement. They are not registered into MNET services.

Function name: ''publishflow_rpc_deploy''

'''purpose:'''
Asking from an external system to deploy a course somwhere in the network.

'''parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier: The value that identifies the course backup, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the MNET host where to deploy.
*parmsoverride: a structure that can override any value of the Moodle "course" record thus deployed instance can have its name, shortname or starting date changed. OPTIONAL.
*json_response: if true, the response is JSONed for convenience with remote XML-RPC implementation.

Function name: ''publishflow_rpc_close_course''

'''Purpose:'''
Asks a remote node to close a course (regarding the course life-cycle handling by the publishflow block)

'''Parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier : the value that identifies the course to be closed, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the node where the course needs to be closed
*mode: The closing mode (see publishflow Course life-Cycle in Training Nodes)
*json_response: (see above).

==Alternate form of the external RPC calls==

Some external applications (ERPs) do not provide support for shooting RPC calls with separate parameters (OfBiz). the two functions above are also available in a wrapped alternate form :

publishflow_rpc_deploy_wrapped($wrap)
publishflow_rpc_close_course_wrapped($wrap)

the wrap is an associative array grouping all required parameters in to a single parameter data bundle. these functions are given as 'adaptors' for that special situations.

Publishflow Block : MNET Services

2012-09-28T21:29:06Z

Vf: /* Service : coursedelivery_data */

Publishflow implements a set of MNET services in order to perform proper across MNET operations.

Here comes the list of MNET XML-RPC functions that are provided by the blocks XML-RPC API.

Please note that the XML-RPC API applied to blocks need using a published patch adding XML-RPC support to blocks in Moodle 1.9. This support is now fully available in Moodle 2.0, although this block is not yet ported forth.

==Service : publishflow==

===Description===

This service is used to hold all RPC related functions for publishflow operations.

===Functions===

delivery_get_sessions() : get information about remotely deployed instances of a course template. Till now, we have feared to interfer too much wich core database model and use the IDNumber of the course to identify similarity between distinct course volumes. i.e. all courses sharing the same value of IDNumber are considered as being instances of an originating course in a factory node.

==Service : coursedelivery_admin==

This service is used to register course delivery commands.

==Functions==

'''delivery_deliver()''': get a course backup from a remote platform. If data transfer is done using local file system, will only give information about the physical location of a course archive.

'''delivery_deploy()''': deploys a course archive where called. This function has to be called remotely from the archive originator that will drive the deployement process (i.e. the deployment IS NOT initiated from the platform you want the course coming in, but where it goes out).

'''delivery_publish()''': similar to the deployment function, but there are some particularities when dealing between a Course Factory and a Course Catalog Moodle instances.

'''publishflow_updateplatforms()''': This function is called by other hosts in a MNET to explore the network and determine which instances are in the MNET neighborhood.

==Other Unregistered XML-RPC Calls==

The following functions entries are XML-RPC functions that were setup for external control of the deployement. They are not registered into MNET services.

Function name: ''publishflow_rpc_deploy''

'''purpose:'''
Asking from an external system to deploy a course somwhere in the network.

'''parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier: The value that identifies the course backup, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the MNET host where to deploy.
*parmsoverride: a structure that can override any value of the Moodle "course" record thus deployed instance can have its name, shortname or starting date changed. OPTIONAL.
*json_response: if true, the response is JSONed for convenience with remote XML-RPC implementation.

Function name: ''publishflow_rpc_close_course''

'''Purpose:'''
Asks a remote node to close a course (regarding the course life-cycle handling by the publishflow block)

'''Parameters:'''
*callinguser: a common authentication structure having fields 'username', 'remoteuserhostroot' and 'remotehostroot' information.
*idfield: one of (id,shortname,idnumber). Designates which attribute will identify the course template to be deployed.
*courseidentifier : the value that identifies the course to be closed, regarding what was choosen as ''idfield''.
*wherewwwroot: the HTTP root identifying the node where the course needs to be closed
*mode: The closing mode (see publishflow Course life-Cycle in Training Nodes)
*json_response: (see above).

==Alternate form of the external RPC calls==

Some external applications (ERPs) do not provide support for shooting RPC calls with separate parameters (OfBiz). the two functions above are also available in a wrapped alternate form :

publishflow_rpc_deploy_wrapped($wrap)
publishflow_rpc_close_course_wrapped($wrap)

the wrap is an associative array grouping all required parameters in to a single parameter data bundle. these functions are given as 'adaptors' for that special situations.