Resetting Admin password

An admin user can login to openXdata and reset all other user’s passwords. However, if you forget your admin password you may be stuck.

In this case, you will need to access your openXdata database directly and reset the default admin. This should really be a last resort measure and you should take care to safeguard your passwords appropriately.

You will need to know the MySQL username and password for your openXdata database or your MySQL root username and password.

To change the password of any user to admin, reset:
* password: 7357bec928a1af86415f7b8c11245296ec1779d
* salt: e2597cf74095403889c6b07b46d8af5d94b8e6

Accessing additional Admin options

Defining new roles, access tasks and settings


The Admin console runs in a seperate window from the Dashboard. To access it click Admin -> Admin (you need Administrator privileges to acces the admin console)

Admin Console


The admin console allows you to modify three openXdata components:

  1. Roles
  2. Tasks
  3. Settings

You may also see a tab Datasets, this is being removed as it is currently non-functional.

Role Management – 1 Add A Role

  1. With any role selected, click the “Add New Child” button
  2. A “New Role” will appear in the left window
  3. Edit the Name of the Role
  4. Select the Roles Management tab to edit the permissions for your new role (See next Step)
  5. Click Save

Role Management – 2 Edit Role Permissions


To add or remove permissions for an existing role or yor newly created role:

  1. Select your role in the left window
  2. Select the Roles Management tab
  3. The left window is a list of all possible permissions that remain available for assignment to the role
  4. Selecting on a permission and using the Add or Remove permission buttons will move the permission from left or right as appropriate
  5. The right window displays the permissions that have been assigned to the role
  6. After editing the permisisons for your role, click save



The Tasks dialog allows you to edit existing tasks, start and stop them (by right clicking on the appropriate task), or add new tasks.

Tasks are run on a schedule like a cron job that is edited in the Schedule tab. Parameters are set in the Parameters tab.

Tasks refer to a java class that specifies the task action, so a new task will likely require some additional coding



The Settings tab allows you to edit various openXdata settings. For example, under User Settings you can enable an email to be sent when a New User is created.

You may need to re-start your openXdata instance after you have edited a setting for it to take effect.

Monitoring you openXdata instance

  1. Click on Admin on top right, next to My Details. (If you do not see this option, you need to ask your administrator for permission)
  2. Select Monitoring

JavaMelody Monitoring


openXdata provides monitoring of your instance through the open source tool, JavaMelody. More information can be found at

Unprocessed data


As explained in How openXdata stores your data, openXdata stores your data in two places. Sometimes, your raw data may be in your database, but you may not be able to view it in the Dashboard because it could not be “processed.”

This happens because of some problem matching yor data to the export table. It can happen because of bugs in openXdata or because something has gone wrong in your database. An example of a current bug that causes a problem is Ticket #254 where you can’t capture integers above a certain length.

If I click View Responses when I am on the selected Sample Form, as show below, I will see only two responses displayed even though the number of responses is listed as 3


Managing unprocessed data

  1. Click on Admin on top right next to My Details (if you do not see this option, you need to ask your administrator for permission)
  2. Select Manage unprocessed data

Open, Delete and Reprocess


The Manage Unprocessed Data window gives you a list of all the data that has not been processed and requires a remedy.

You can correct the problem, by editing using (1) Open, (2) Deleting it, or by making other corrections at the database level.


  • Select the form you wish to edit
  • Click Open and you will be taken to the form runner – note you will need a form layout designed for your form
  • Alter the form as appropriate and click Submit
  • If your edit was correct and you have no more data to reprocess you will probably notice the triangle has gone from the List of Forms
  • Click the Refresh button and if the form has disappeared your edit was successful

Note that copies of the data that was originally entered are still stored in the database in the form_data_version table


  • Delete any forms that you don’t want to reprocess by selecting them and clicking Delete


  • If you have made modifications at the database level or elsewhere and you want to trigger openXdata to attempt to process the data again select the relevant forms and click Reprocess. If they are removed from the list then they have successfully been exported to your table and you will be able to view the data from the Dashboard.

How openXdata stores your data

In a MySQL database

All the data you collect in openXdata is stored in the MySQL database that you setup in the first step. It is worth noting here that openXdata (the software) does not do anything to secure your database for you, you must take your own steps to ensure the integrity and security of your database (and your backups). In addition openXdata (the organization) cannot see or access or control your data – it is yours to own, use and protect.

Inside the database, it goes into two or more places:

  1. standard table: form_data
  2. standard table: form_data_version (only used when data is edited)
  3. custom table: table of data per form
  4. custom table: table of data for any repeat questions (only when form has repeat questions)



The table form_data stores the raw xml of your data in the column data.

The xml for your data will contain all of the fields in your form and any data you’ve stored, for example:

<?xml version="1.0" encoding="UTF-8"?>
<example_study_sample_form_v1 formKey="example_study_sample_form_v1" id="1" name="Sample Form_v1" xmlns:xsd="">
<last_name>Testing Form 1</last_name>
<endtime>09:49:27 PM</endtime>

Each data entry is given a unique ID, and it retains that ID when you edit it.

The version of your data entry in the table form_data will be the latest version of that particular data entry



The table form_data_version stores old versions of the data when a data entry is edited. It also includes information useful for audit trails like who changed the data and when.

custom table


For each form, a unique table, or tables is created.

These tables have the same name as the form version binding or the repeat question binding. (See the Glossary for more information on bindings)

These tables have the data broken out into columns with the column headings being the question bindings.

In 1.16 there are some protections to prevent a clash of table names but they can still happen. In particular:

  • Importing a form that already exists in the database
  • Creating a repeat question with the same binding

Managing Tasks and Settings

Includes instructions on how to configure Data Export task for use with EMIT (~1:08)  – only necessary with v1-2