Corteza Discovery provides a powerful search engine to interact with your data. Corteza Discovery defines an intuitive interface to search and, in some cases, visualize the data such as geographical metadata.
To access Corteza Discovery, navigate to your Corteza instance and click on the Discovery application.
In the Corteza Discovery application you are presented with an intuitive user interface where the general filters are available on the left side of the screen, a search box on the top, and the search results just below the search box.
To find exactly what you’re looking for, apply a general filter. It is located on the left side of the screen. Click on the checkbox next to a filter to apply it to the search results.
You can insert a search query in the input box on the top of the screen to filter over the remaining search results. The querying tries to find the best results based on the available data and the search term you’ve provided.
Visualizing a Geographical Location
If a search result defines a geographical location, it can be visualized on a map. To visualize search results on a map, click on the map button in the bottom-right corner.
When you click on the map button a map appears right from the resulting data. Mappable search results are represented as pins on the map; search results that can not be mapped are omitted from the map but still preserved in search results.
Corteza Discovery is a stand alone application, independent from the rest of the Corteza system. In order to make Discovery functional, you must grant access by creating an auth client along with a user and a role.
Access control defines what data the Discovery indexer has access to; more in the index configuration sections.
Firstly define a new role for the Discovery indexer to use. Open the Corteza Admin web application and navigate to. Click on the new button, fill in the parameters and click on the submit button.
Next, define a new user that the Discovery indexer should identify as. In the Corteza Admin web application navigate to. Click on the new button and fill in the parameters and click on the submit button.
After you save the user, assign them the role you’ve created earlier.
Indexer Auth Client
Lastly, define an auth client that the Discovery indexer should use to authenticate with Corteza.
Since authentication between two systems is being performed, you should to use the
In the Corteza Admin web application navigate to
client_credentials grant type and check the
allow client access to Corteza Discovery API on behalf of user.
Select the previously created user in the
impersonate user input and click on the submit button.
It is recommended you define a new auth client for a new external application instead of reusing existing ones.
Copy the client ID and client secret from the auth client and keep them safe for later use. The clientID is located in the URL address bar, and the client secret is in the field labeled as such
Data visibility defines what is indexed and is controlled by the standard access control facility. The Discovery indexes everything it currently has access to.
To control data visibility, configure access control rules for the role we’ve defined in the integration configuration section above.
Refer to the example where the indexer is limited to only show records from a specified namespace.
Indexing policy defines how the data is indexed and who it can be accessed by. Indexing policy allows you to make specific fields accessible publicly or only for authenticated users.
Currently, the indexing policy applies to specific fields. To control entire rows, use data visibility.
There are three policies: private, protected, and public. The private policy is used by default.
Currently, only compose modules allow custom indexing policy.
If a resource supports indexing policy, there is a discovery settings button on the configuration page.
When you click on the discovery settings button, a popup opens. It presents the index policy configurator.
To configure the policy, click on the corresponding tab and add the fields you wish to apply the policy to.
If a search result is covered by multiple index policies, the one covered by the most restricting policy is returned.
Private indexing policy is used by known, authenticated users to do cross-system searches.
Private index policy should be used whenever indexing sensitive data or data you don’t wish to expose publicly.
Protected indexing policy is meant for foreign systems that are under some kind of access control.
Protected indexing policy should be used when you have an external system accessing the data and that external system performs the required access control.
If external systems are not involved, use either private or public indexing policies.
Public indexing policy is meant for users that are not logged-in.
Public indexing policy should be used when you want to make data available publicly without the need to know who is accessing it.