Enhanced Filter Operators for Custom Attributes in Automation Rules
Is your feature or enhancement related to a problem? Please describe.
Summary
Currently, custom attributes in automation rules have limited filter operator support based on their data type. This feature request proposes enhancing the operator support to provide more flexible filtering options, particularly for text and date custom attributes.
Problem Statement
When creating automation rules with custom attributes, users are limited in the operators they can use:
Text attributes only support: equal_to, not_equal_to, is_present, is_not_present Number/List/Checkbox attributes only support: equal_to, not_equal_to Date attributes only support: equal_to, not_equal_to, is_present, is_not_present, is_greater_than, is_less_than However, text attributes would benefit from contains and does_not_contain operators (similar to how the standard content field works), and the current implementation doesn't consistently apply operators based on attribute type.
Describe the solution you'd like
Proposed Solution
- Enhanced Text Attribute Operators
Add support for contains and does_not_contain operators for text custom attributes:
Current operators for text:
Equal to Not equal to Is present Is not present Proposed operators for text:
Equal to Not equal to Contains ✨ (new) Does not contain ✨ (new) Is present Is not present This would match the functionality available for the standard content field in message filters.
- Consistent Operator Application
Ensure that operators are correctly applied based on custom attribute display type, both when creating new automation rules and when editing existing ones.
Use Cases
Text Search in Custom Attributes:
Filter conversations where a custom text field "Customer Notes" contains "urgent" Filter conversations where "Product Name" does not contain "discontinued" Better Date Filtering:
Currently works, but should be consistent across all attribute types Improved User Experience:
Users expect similar operators for text fields regardless of whether they're standard or custom attributes Technical Implementation
Frontend Changes
File: app/javascript/dashboard/helper/automationHelper.js
The getOperatorTypes function should return OPERATOR_TYPES_7 for text attributes, which includes all 6 operators:
export const getOperatorTypes = key => { const operatorMap = { list: OPERATOR_TYPES_1, text: OPERATOR_TYPES_7, // Includes: equal_to, not_equal_to, contains, does_not_contain, is_present, is_not_present number: OPERATOR_TYPES_1, link: OPERATOR_TYPES_1, date: OPERATOR_TYPES_4, checkbox: OPERATOR_TYPES_1, };
return operatorMap[key] || OPERATOR_TYPES_1; }; File: app/javascript/dashboard/routes/dashboard/settings/automation/operators.js
Ensure OPERATOR_TYPES_7 is defined with all 6 operators:
export const OPERATOR_TYPES_7 = [ { value: 'equal_to', label: 'Equal to' }, { value: 'not_equal_to', label: 'Not equal to' }, { value: 'contains', label: 'Contains' }, { value: 'does_not_contain', label: 'Does not contain' }, { value: 'is_present', label: 'Is present' }, { value: 'is_not_present', label: 'Is not present' }, ]; File: app/javascript/dashboard/helper/automationHelper.js
The getOperators function should check for custom attributes in both create and edit modes:
export const getOperators = ( allCustomAttributes, automationTypes, automation, mode, key ) => { // Check for custom attributes in both edit and create modes const customAttribute = isACustomAttribute(allCustomAttributes, key); if (customAttribute) { return getOperatorTypes(customAttribute.attribute_display_type); }
// Fall back to standard automation types for non-custom attributes const type = getAutomationType(automationTypes, automation, key); return type?.filterOperators ?? []; }; Backend Changes
File: app/services/filter_service.rb
The backend already supports contains and does_not_contain operators through the ilike_filter_string method. The filter service properly handles these operators for custom attributes:
def filter_operation(query_hash, current_index) case query_hash[:filter_operator] when 'equal_to', 'not_equal_to' @filter_values["value_#{current_index}"] = filter_values(query_hash) equals_to_filter_string(query_hash[:filter_operator], current_index) when 'contains', 'does_not_contain' @filter_values["value_#{current_index}"] = values_for_ilike(query_hash) ilike_filter_string(query_hash[:filter_operator], current_index)
... other operators
end end The backend validation in app/services/automation_rules/condition_validation_service.rb should also be updated to allow these operators for text custom attributes.
Benefits
Consistency: Text custom attributes will have the same operators as standard text fields Flexibility: Users can create more sophisticated automation rules User Experience: Matches user expectations from other parts of the system Backward Compatible: Existing automation rules will continue to work Testing Checklist
Text custom attributes show all 6 operators in create mode Text custom attributes show all 6 operators in edit mode contains operator works correctly with text custom attributes does_not_contain operator works correctly with text custom attributes Other attribute types (number, date, list, checkbox) maintain their current operators Backend validation accepts the new operators for text attributes Existing automation rules continue to work after the change Related Issues
This enhancement would improve the consistency and usability of automation rules, making custom attributes more powerful and intuitive to use.
Additional Notes
The implementation is relatively straightforward as:
The backend already supports these operators The operator types are already defined in the frontend The main change is ensuring the correct operator set is applied based on attribute type This is a low-risk, high-value enhancement that would significantly improve the automation rules feature.
Describe alternatives you've considered
No response
Additional context
No response
Source: chatwoot/chatwoot