Skip to main content

​
Introduction to the Filter_Conditions Table

The filter_conditions table is designed to store and manage filter conditions for process steps in the Serial application. This table plays a crucial role in enabling dynamic filtering of data and controlling the visibility of process steps based on specific criteria.

​
Table Structure

The filter_conditions table is structured to capture various aspects of a filter condition, including its associated company, process step, type, and operator. Here’s a detailed breakdown of its columns:
Column NameData TypeConstraintsDescription
iduuidprimary keyUnique identifier for the filter condition
company_iduuidnot null, foreign keyReference to the associated company
process_step_iduuidReference to the associated process step
nametextnot nullName of the filter condition
typetextnot nullType of the filter condition
dataset_iduuidReference to the associated dataset (if applicable)
operatortextnot nullOperator used for the filter condition
valuetextnot nullValue to compare against in the filter condition
labeltextOptional label for the filter condition
created_attimestampnot null, default now()Timestamp of when the filter condition was created

​
Usage and Functionality

The filter_conditions table is designed to be flexible and support various types of filtering operations. Here are some key points about its usage:
  1. Process Step Association: Each filter condition is typically associated with a specific process step through the process_step_id column. This allows for step-specific filtering within a process.
  2. Company-Specific Filtering: The company_id column ensures that filter conditions are segregated by company, allowing for company-specific configurations.
  3. Flexible Condition Types: The type column allows for different types of filter conditions, which can be used to filter various data types such as numeric values, dates, or categorical data.
  4. Customizable Operators: The operator column stores the comparison operator (e.g., equals, not equals, greater than) used in the filter condition, providing flexibility in how conditions are evaluated.
  5. Security and Access Control: Row-level security policies ensure that only users with the ‘ADMIN’ role from the same company can modify (insert, update, delete) filter conditions, while all users from the same company can view them.

​
Notes

  • The table includes indexes on company_id and process_step_id columns to optimize query performance when filtering by these attributes.
  • The dataset_id column allows for linking filter conditions to specific datasets, which can be useful for more complex filtering scenarios.
  • Example usage in TypeScript: 
    const allowedOperators = {
  [CollectionType.ParametricQuantitative]: [
    FilterConditionOperator.Equals,
    FilterConditionOperator.NotEquals,
    FilterConditionOperator.GreaterThan,
    FilterConditionOperator.LessThan,
    FilterConditionOperator.GreaterThanOrEqualTo,
    FilterConditionOperator.LessThanOrEqualTo,
  ],
  // ... other collection types
};
  • The testFilterCondition and testFilter functions in the codebase are used to evaluate filter conditions against actual data, determining whether a specific data point meets the criteria defined in the filter_conditions table.
By leveraging the filter_conditions table, the Serial application can implement dynamic and flexible filtering mechanisms, allowing users to customize their data views and control the visibility of process steps based on specific criteria. This enhances the application’s ability to handle complex workflows and data management scenarios across different companies and processes.