Filters

In Anjana Data, filters allow users to refine searches and display relevant information in different contexts of the Data Portal (search engine and audit screens).

Screens of the Data Portal with configurable filters

There are different screens in the Data Portal that allow customizing the filters offered to users:

Search Portal filters

The Search Portal has filters configured by default, meaning they appear statically at the top. Additionally, the user can add more filters by selecting from among the filters configured by the organization, via the Filters > Add filter option.

Filters for entity-type attributes

Entity-type attributes have a filter that facilitates the search and location of entities. They display the same default filters and on-demand additional filters as in the Search Portal.

Audit module filters

The global audit module has filters by certain types of metadata and supports a certain degree of configuration.

Object audit module filters

The audit module for an object (entity or relationship) has filters by certain types of metadata and supports a certain degree of configuration.

User audit module filters

Each user can view their own audit in their profile, where they have filters that facilitate locating the corresponding records. These filters support a certain degree of customization by certain metadata.

Filter Conf Table in the Configuration Panel (Administrator view)

These filters are defined in the Filter Conf table of the Configuration Portal and determine which metadata can be used as a search criterion, what their type is, etc.

Structure of the Filter Conf table

Each registered filter is characterized by the following fields:

• Id: unique identifier of the filter. It is assigned automatically from the Configuration Panel.

• Name: field used to indicate which metadata attribute the filter applies to.

  • When the filter corresponds to a metadata attribute defined in the Attribute Definition table, the Name value must be configured in uppercase based on the name field of that table.

    • Example: if in Attribute Definition there is an attribute with name = dominio, the filter must be configured with Name = DOMINIO.

  • When the filter corresponds to fields related to the system Audit, the name value refers to the fields of the minerva.audit_log table (internal data model table), which stores the internal and external audit of Anjana Data. Possible values for audit:

    • action: allows filtering by the different governance actions (e.g.: Creation, Modification, Adherence…). The filter Type must be of type MULTI_SELECT and the Label must have the value FILTERS.ACTION.

    • logOrigin: allows filtering by the origin of the audit. The internal audit of Anjana Data (e.g.: Creation, Modification, Adherence… actions) has logOrigin “anjana”, while the external audit injected via API will have the value defined by the organization. The Type of this filter must be of type MULTI_SELECT and the Label must have the value FILTERS.LOG_ORIGIN.

    • objectName: indicates the logical name of the Data Portal asset for which the audit is recorded (e.g.: the “Product codes” dataset). The filter Type must be of type ENTITY and the Label must have the value FILTERS.OBJ_NAME.

    • objectType: allows filtering by object type, i.e., by ENTITY or RELATIONSHIP. The filter Type must be of type MULTI_SELECT and the Label must have the value FILTERS.OBJ_TYPE.

    • objectSubtype: allows filtering by object subtype, i.e., by the different types of entities and relationships configured in the metamodel. The filter Type must be of type MULTI_SELECT and the Label must have the value FILTERS.OBJ_SUB_TYPE.

    • startTime: allows filtering audit records within a date range (start and end). The filter Type must be of type INPUT_DATE_RANGE and the Label must have the value COMMON.DATE.

    • userName: allows filtering audit records by the user who originated them. The filter Type must be of type SELECT_USERS and the Label must have the value FILTERS.USER.

• Label: this is the translation key for the visible name of the filter in the Data Portal. The label must be formed as follows:

  FILTERS.<name en Attribute Definitions>
  

• Type: allows selecting the filter type from among the available types. It must correspond to the type of the attribute it applies to (see the table available in the following section).

• collection: refers to the data collection to which the filter applies in the indexer technology. The user must choose from the following values depending on the module for which the filter is configured:

  • Kerno → Used to configure filters in the Search Portal of the Data Portal. These filters allow searching within the data asset inventory and information.

  • Audit Logs → Used to configure filters in the Audit module. These filters allow searching through the history of governance actions and external audit.
    

    

• pageName: used to indicate the page to which the filter applies. The possible values are:

  • empty → Applies only to Search Portal filters (collection= kerno) or to all audit modules (Global audit, object audit or user audit)

  • AUDIT_ALL → Applies only to the Global Audit module.

  • AUDIT_USER → Applies only to the User Audit module.

  • AUDIT_OBJECT → Applies only to the Object Audit module.

• main: boolean field that applies only to Search Portal filters:

  • true → Mark so that the filter appears by default in the filter bar of the Search Portal and in the filters for ENTITY-type attributes. In Audit filters, main must always be set to true.

  • false → Uncheck so that the user can add the filter in the Search Portal if desired, via the Filters > Add filter option (false).
    

    

• position: used to set the order in which filters are displayed in the interface.

• sortable: currently not used (legacy field). Can be left as false.

Important:

Any error in the configuration of the Search Portal filters can trigger the message “Solr: undefined field”, preventing the normal operation of the portal.

The most common causes are:

1. Creating a filter on an attribute that is not assigned to any template.
   Solr cannot index attributes that are not part of the effective metamodel of the objects. Since the attribute does not exist in SOLR, it cannot be used as a filter.

2. Creating a filter on an uninitialized attribute.
   That is, the attribute exists in the template of some object subtype, but no asset in the portal has a value for it.
   In these cases, Solr does not generate the field in its index and the filter causes the error.

   To avoid this, it is recommended to initialize the attribute before creating the filter, for example through a bulk edit on all objects that include it in their template, assigning an empty or null value as appropriate.

3. Filter configuration error.
   If the filter is configured with an attribute that does not exist, i.e., the name does not correspond to any attribute in the Attribute Definition table, the filter causes the error.

Filter types

The following shows the different types of filters that can be configured according to the type of metadata for which the filter is configured:

Adding a Filter to the Filter Conf table

Adding a new filter is done in the Configuration Panel

Steps to add a filter in the Search Portal:

1. Click the New button in the top right corner.

2. Fill in the fields according to the table structure:

   • name: filter identifier in uppercase (e.g.: DOMINIO).

   • Label: associated translation key (e.g.: FILTERS.DOMINIO).

   • Collection: choose the collection corresponding to the Search Portal (kerno).

   • pageName: as this is a search portal filter, this field is left empty.

   • Type: select the filter type (e.g.: MULTI_SELECT_TREE since it is a taxonomy tree type attribute).

   • main: check if the filter should appear by default in the filter bar (e.g.: true).

   • position: indicate the display order in the filter bar (e.g.: 4)

   • sortable: leave as false.

3. Click Save to save the filter or Cancel to discard it.

Steps to add a filter in all audit modules (global, object and user):

1. Click the New button in the top right corner.

2. Fill in the fields according to the table structure:

   • Name: filter identifier in uppercase (e.g.: objectName).

   • Label: associated translation key (e.g.: FILTERS.OBJ_NAME).

   • Collection: choose the collection corresponding to the Search Portal (Audit Logs).

   • pageName: indicate the page. In this case, since it applies to all audit modules (global, object and user), it is left empty.

   • Type: select the filter type (e.g.: ENTITY as it is an entity-type filter).

   • main: since it is an audit filter, it must be true.

   • position: indicate the display order in the filter bar (e.g.: 4)

   • sortable: leave as false.

3. Click Save to save the filter or Cancel to discard it.

Modifying a Filter in the Filter Conf table

Modifying an existing filter can be done at any time, since it only affects the display and behavior of the modules in which the filter is used (search engine or audit).

The following fields can be freely modified, always respecting the restrictions on possible values:

• main: to indicate whether the filter should appear as static or configurable by the user.

• position: to adjust the order in which filters are displayed in the interface.

• Type: to change the filter type, always selecting a valid one based on the type of attribute it applies to.

• pageName: to redefine the screens or sections of the application where the filter will be available.

The remaining fields (Name, Collection andLabel ) must not be modified, except to correct configuration errors made during initial setup.

At any time it is possible to add new filters or remove existing filters, depending on the display needs or the modules enabled in the Data Portal.

* Advanced filters

Indexed documents contain internal metadata that can sometimes be very useful; some common use cases may be:

• Search dataset fields filtering by dataset name (Name = DATASET_NAME , Label= FILTERS.DATASET_NAME)

• Search relationships filtering by the source entity subtype (Name = SOURCE_TYPE, Label= FILTERS.SOURCE_TYPE)

• Search relationships filtering by the destination entity subtype (Name = DESTINATION_TYPE, Label= FILTERS.DESTINATION_TYPE)

These metadata are indexed and can be configured as filters:

Filter Configuration via direct database access (Developer view)

Filters are stored in the minerva.filter_conf table.

Definition of several filters in the different modules of the Data Portal:

INSERT INTO minerva.filter_conf
(id, collection, "label", main, filter_name, "position", sortable, "type", page_name)
VALUES
(69, 'kerno', 'FILTERS.DOMINIO', true, 'DOMINIO', 4, false, 'MULTI_SELECT_TREE', NULL),
(64, 'kerno', 'FILTERS.NIVELRIESGO', false, 'NIVELRIESGO', 15, false, 'MULTI_SELECT', NULL),
(62, 'kerno', 'FILTERS.NIVELGOBIERNO', true, 'NIVELGOBIERNO', 8, false, 'MULTI_SELECT', NULL),
(49, 'audit_logs', 'FILTERS.OBJ_SUB_TYPE', true, 'objectSubType', 3, true, 'MULTI_SELECT', 'AUDIT_USER'),
(48, 'audit_logs', 'FILTERS.USER', true, 'userName', 2, true, 'MULTI_SELECT', 'AUDIT_USER'),
(40, 'audit_logs', 'FILTERS.OBJ_SUB_TYPE', true, 'objectSubType', 4, true, 'MULTI_SELECT', 'AUDIT_ALL'),
(39, 'audit_logs', 'FILTERS.OBJ_TYPE', true, 'objectType', 3, true, 'MULTI_SELECT', 'AUDIT_ALL');