2023:Overrides (UI Element): Difference between revisions
No edit summary |
No edit summary |
||
| Line 72: | Line 72: | ||
#* 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. | #* 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. | # 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. | ||
|| [[File: | || [[File:2023_Overrides_02_How-To_04.png]] | ||
|} | |} | ||
</tab> | </tab> | ||
| Line 87: | Line 87: | ||
<p/><br/> | <p/><br/> | ||
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. | 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. | ||
|| [[File: | || [[File:2023_Overrides_02_How-To_05.png]] | ||
|} | |} | ||
</tab> | </tab> | ||
Revision as of 15:05, 9 November 2023
Overrides is a tab provided to allow overriding of default properties set to a Data Element.
| Previous Versions |
|---|
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.
|
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 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.
|
|
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.
|
|
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.