Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Primary mentor

Unlicensed user

Backup mentor

TBD

Assigned to

Unlicensed user

Abstract

The validation module is a useful tool for finding problems with your DB. It runs OpenMRS validators against different data and matadata in your system. It is particularly handy for implementations migrating to OpenMRS 1.9. In OpenMRS versions earlier than 1.9 objects were not always validated before persisting them to the DB and after upgrading to OpenMRS 1.9 you may want to make sure that your objects are valid before discovering that only after trying to modify them.

The goal of this project is to enhance the Validation module by providing a more polished UI, improved error reports and automatic fixes for common problems.

Objectives

  • Make it possible to select the type of metadata or data to validate instead of typing a fully qualified class name

The present validation module UI provides a text field to enter the type of Data or Metadata that needs to be validated, but this requires to enter the full name of Data/Metadata (e.g. org.openmrs.Concept). With this new tag I am going to replace this text field with a combo box where all the types of classes are given as options in the combo box such as 'Concept', 'Drug' etc. In addition there are two more options named 'All Data' and 'All Metadata'. If user selects one of these the system will validate all metadata or data therefore this choice provides a way to validate the whole database items at once.

For the design, please refer Diagram 1: Validation Module Main UI Design in 'UI Mockups' page.

  • Add a way to stop validation

This new feature is added in order to stop the validation in middle once the validation is started. At the moment there is no support to stop the validation from UI. However if the user stops the validation, he may need to start back the validation using 'Submit Query' option as there is no way to resume the previous validation threads back.

For the design, please refer Diagram 1: Validation Module Main UI Design in 'UI Mockups' page.

Progress

The above two tasks have been currently implemented and the documentation can be found Validation Module Documentation for reference.

 

  • Combine reports produced by different threads into one

The main use of Validation module from a user's perspective is getting a list of errors in the Objects which are stored in the database. At present validation UI displays the list of validation results separated into number of threads and one has to click on each 'show report' link when it is needed to see the errors. This deprives the user's requirement therefore with this task, the validation UI will be changed to display a single combined report of errors in the validated objects.

For the design, please refer Diagram 2: Report Page UI Design in 'UI Mockups' page.

  • Group validation errors by the type of error e.g. group all errors saying "at least one non-empty name is required for a concept" together

This feature is also added into the report page described in task 3, where the combined validation results will be displayed in a separate table , based on the Error type instead of the Class type. We may simply use the validationErrors Map as in above task along with the Object type and readjust the Errors list table using the data obtained from those.

For the design, please refer Diagram 2: Report Page UI Design in  'UI Mockups' page.

  • Make it easier to fix common errors in Concepts e.g. "at least one non-empty name is required for a concept" should allow you to display the given concept and add a missing name, "'epilepsia frontal' is a duplicate name in locale 'es'" should allow you to display all conflicting concepts with this name, etc.

This is done by newly adding a “Fix” link into each error related to Concept class, displayed in the Report tables. When the user clicks the 'Fix' link, it will be redirected to the OpenMRS Concept Edit page with the corresponding Concept ID that has the error. According to the validation code, this Concept ID, is the error.id of each entry in the results table. Once the page is redirected user can fix the issue in the 'Edit Concept' page, save it back and return to the Report page.

For e.g If it is a 'DuplicateConceptNameException' the user can change the Concept name into something else in the ''Edit Concept' page.

For the design, please refer Diagram 2: Report Page UI Design in  'UI Mockups' page.

  • Update documentation on the wiki and prepare a screencast.

See also an epic ticket for this: https://tickets.openmrs.org/browse/TRUNK-3730 (soon to be moved to a dedicated JIRA project)

Extra Credit

  • Add quick fixes for errors in types different than Concepts

As suggested above when there are errors found in Concept objects, each can be corrected by directing them to 'Edit Concept' page. Similar to this, if we extend this method in more advanced way this can be used to fix certain types of errors in other validation objects than Concept. What needs to be done is call the corresponding Error ID (which is the unique identifier ID of the object of any type) from the validation results list and redirect to the matching 'Edit' page based on the object type. The fix which needs to be done can be applied in the 'Edit' page and save back the object.

E.g. If there is DuplicateIdentifierException in a Patient object, this can be redirected to href=”http://localhost:8080/openmrs/admin/patients/patient.form?patientId=3” page and edit the patient identifier. The patientId which is 3 in this case is the given Error ID in the result list.

For the design, please refer Diagram 3: Extra credit UIs design in  'UI Mockups' page.

  • Display progress and estimated time needed to complete validation

In order to do this it is needed to first practically test on the average validation time for a single object. Then a new algorithm to be written to get the total number of objects as input and calculate the estimated total validation time. This time is displayed in the UI. A progress bar will also be displayed in the UI which will start showing the progress once the first ValidationThread starts and complete the progress with the Last ValidationThread finished the process.

For the design, please refer Diagram 3: Extra credit UIs Design in 'UI Mockups' page.

Note: It it expected to complete extra credit task 01 within the GSoC time and the task 02 will be only addressed if there is time remaining.

Resources

UI Mockups page

  • No labels