2023:Overrides (UI Element)

This is a snippet of in Design showing the Overrides tab.

Overrides is a tab provided to allow overriding of default properties set to a Data Element.

Previous Versions
Data Element Overrides - 2.90

About

You may download and import the file(s) below into your own Grooper environment (version 2023). There is a Batch with the example document(s) discussed in this tutorial, as well as a Project configured according to its instructions. Please upload the Project to your Grooper environment before uploading the Batch. This will allow the documents within the Batch to maintain their classification status. Media:Overrides_-_Project_(v2023).zip Media:Overrides_-_Batch_(v2023).zip

Grooper solutions can range from simple scan and archive processes to extremely complex solutions. Overrides allow discrete control of Data Elements on a per Content Type basis. This greatly magnifies Grooper’s inheritance-based architecture and allows for more robust and scalable Data Models. You are no longer required to make copies of Data Elements when you just need to modify a property for an oddball Document Type. This can greatly save time building the solution and reduce complexity by eliminating those copied Data Elements. One can also quickly and easily Test Extraction directly in the Overrides tab. After modifying any of the Data Element properties, you can easily test the results of the modification against a test Batch without leaving the tab.

How To

Following is an example of how to setup Overrides. In this example are three different document formats, all of which are collecting the same data. Format A and B follow a similar enough structure and will not use an override to extract. Format C is different enough that it will override the default extractor to get its data.

!	Some of the tabs in this tutorial are longer than the others. Please scroll to the bottom of each step's tab before going to the step.

Understanding the FormsSetting up the OverrideTesting the Results

Understanding the Forms

In the image on the right you can see that "YES" / "NO" values are being returned from the "Document Format A". The Data Model's child Data Elements are set up with simple Labeled Value extraction logic to find the "Value (1,2,3)" labels and return a "YES" or a "NO".

The same can be seen for "Document Format B". Even thogh the orientation of the results is different from "Document Forma A", the Labeled Value approach still works here.

However, with "Document Format C" we are still returning results, but not from the simple Labeled Value settings used on the Data Elements of the Data Model. An override on the "Document Format C" Document Type is being leveraged to allow the OMR checkboxes to be detected and return "YES" / "NO" results.

Setting up the Override

Setting up a Data Element Override is quite simple. Select a Content Type, in this case, a Document Type. Yes, Overrides can be applied to Content Categories. Select the Overrides tab. Select a Data Element you want to set overrides for, in this case a Data Field. Note that Data Elements that have had properties overridden will have an orage asterisk near them, as well as an orage numeric value in parenthsis indicating the amount of properties overridden. Properties overridden will also have an orange asterisk near them. You will see here the Labeled Value setting of the Value Extractor has been changed to Labeled OMR. It's sub-properties have been set to accomodate for this.

Testing the Results

The crux of this all is that you can now use the main Data Model, with the same established Data Elements, and get results from all the forms. Click on the Data Model. Click the "Tester" tab. Click on the document you want to extract from. Click Test Extraction Rinse and repeat for the other documents. Document Format C will now successfully extract due to the overrides. It's important to note that because the Overrides are applied to a Content Type a document must be properly classified in order for the Data Model to know that overrides would be used for extraction for that document. You may be able to successfully test results from the Overrides interface without a classified document, but doing so on the Data Model will result in no extraction.

A simpler, perhaps more common, example of where Overrides very much come in handy is with the visibility of Data Elements. One of the properties of a Data Element is the Visible property which is default True. Imagine a Data Model that has five Data Fields, and the Content Model has 3 Document Types. Document1 uses Data Fields 1-3, Document2 uses Data Fields 2-4, and Document3 uses Data Fields 3-5. In Data Review you want to simplify the job for the person reviewing, so you do not want them to concern themselves with fields that are not relevant. To accomplish this you could use Overrides on each of the aforementioned hypothetical Document Types and set the Visible property to False on all the fields you don't need. This would keep only relevant Data Fields visibile upon review.