Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

The reporting module allows you to define parameters to collect information from the user. You're able to add parameters in the reporting module design process. Click + Add in the header of the Parameters box to add a parameter to the report.


Collection Type: The first drop down box allows you to collect a single parameter a list of parameters or a set of parameters. The list and set types present a plus box next to the input allowing users to add as many parameters as they like.

Parameter Type: The second drop down box allows you to choose one of the many java and OpenMRS parameter types that are defined throughout the system. The list is exhaustive, but common parameter types include boolean which allows you to collect 0 or 1 values, date which pops up the date picker widget, integer, long which collects long integers, float which collects decimal point numbers and string. These parameters are displayed to the user using the presentation that is defined in the HTML Widgets Module.


This field is the name that is used to reference the parameter within the report. In a SQL data set definition, you would use a semicolon to preface the name of the parameter. For example, select * from openmrs.person where id=:id;


This is the value that's displayed to the user. Note that these labels are not affected by translations.

Advanced Configuration

The "Advanced Configuration" area provides an additional means of controlling how a particular parameter widget is rendered for entry. The expected format is as "properties" (key=value pairs, one pair per line). Each property is passed in as an "attribute" to the htmlwidget handler that is responsible for rendering the widget for that parameter, based on it's chosen type. These supported attributes, if they were documented at all, would be listed here: HTML Widgets Module. Each parameter type listed above has a unique set of attributes that can be added in this section.

Here are a few concrete examples:

Type: String

The following entry converts a string to a drop down window with the selected value forwarded to the report:


If you need your options to contain commas, you can change the separator by adding the following value in a new line:


Type: Concept

If your parameter is of type Concept, you could have an entry that looks like this:


This would limit the available Concepts to choose from for this parameter to only those that are Diagnoses.

Or, you could have an entry that looks like this:


This would limit the available Concepts to choose from for this parameter to only those that are configured as valid answers to this Concept.

If your parameter is of type Concept, you could have an entry that looks like this:

optionHeader=Choose a Location...

And this would display this text, rather than an empty value, as what appears in the select list for a Location parameter.


  • Each of the available attributes can be found in the source code of the HTML Widgets module
  • These parameters are not as robust as the HTML form entry module.
  • There doesn't appear to be any method to add validation to the parameters in the reporting module.
  • No labels


  1. Unknown User (arbaughj)

    When passing a boolean parameter into an SQL query, it appears to yield a text string of "true" or "false".  This happens with Reporting 0.8.1. If you want to add a condition "WHERE true=true" using the boolean parameter like "WHERE true=:parameterName" it fails.  As a work-around you can use "WHERE 'true' LIKE :parameterName" which will do the comparison as a text string.  

    1. Unknown User (arbaughj)

      This issue was raised in REPORT-585, and fixed in Reporting 0.8.2.  You can now use "WHERE :parameterName=true".

  2. Unknown User (arbaughj)

    It is possible use a boolean to select a different version of a query, depending on a parameter.  Create a boolean parameter, for example "choleraOnly".  Then create your two different versions of the query.  In this example, one that would include all results, and another that would include only cholera results.  Join them with a "UNION" between them.  Then, in the WHERE section of one query add "AND :choleraOnly=true" and in the other, add "AND :choleraOnly=false".  This will allow you to have two different versions of an SQL DataSet accessible at run-time with a parameter.  I admit it's not the most elegant solution, but it is functional, and helps reduce the clutter of multiple datasets and multiple reports.