From b2f8b9a178c03314636e17c7df131a6cfd061272 Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Wed, 18 Feb 2026 12:05:09 +0000 Subject: [PATCH 1/2] Update required filter docs: field locked, value/operator editable Generated-By: mintlify-agent --- references/tables.mdx | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/references/tables.mdx b/references/tables.mdx index 6529ea24..1a915c24 100644 --- a/references/tables.mdx +++ b/references/tables.mdx @@ -595,7 +595,7 @@ The order that the fields are listed in `default_show_underlying_values` is the Use `default_filters` to define filters on Dimensions that will be applied when no other user-defined filter on those Dimensions exists. Default filters will apply to tables on load and can be populated with a pre-determined value. Use them to suggest to users the kind of filters they might want to consider, or provide a default filtered view of a table that can be changed if needed. -An optional `required` flag can be added - in which case the filter _cannot_ be removed or modified. This can be particulalry useful if you have a large table and want to force users to filter on a partitioned date. +An optional `required` flag can be added - in which case the filter _cannot_ be removed. This can be particularly useful if you have a large table and want to force users to filter on a partitioned date. Below you can see there is a default filter with the optional required flag, that will have show the last 14 days of data by default. @@ -652,9 +652,11 @@ Below you can see there is a default filter with the optional required flag, tha - When a filter has `required: true`, the filter is completely locked in the UI — the field, operator, and value cannot be modified, and the filter cannot be removed. It will always be applied exactly as defined in the model YAML. + When a filter has `required: true`, the filter cannot be removed from the UI, and the field cannot be changed. However, users can still modify the operator and value to adjust the filter as needed. This ensures the filter is always applied while giving users flexibility to change the date range or other values. In contrast, when `required: false` (or omitted), the filter is pre-populated but fully editable — users can change the field, operator, value, or remove it entirely. + + Note: Required filters are not a security feature. For secure data access control, use [user attributes](/references/user-attributes). ### If you have many filters in your list, they will be joined using `AND` From 14740dd4a3b1dcc930bb2a82f0c9524cac824b66 Mon Sep 17 00:00:00 2001 From: Jess Hitchcock Date: Wed, 18 Feb 2026 12:36:27 +0000 Subject: [PATCH 2/2] Enhance explanation of required filters in tables.mdx Clarify the behavior of required filters in the documentation, explaining how users can modify operators and values while ensuring filters are applied. --- references/tables.mdx | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/references/tables.mdx b/references/tables.mdx index 1a915c24..25788f4a 100644 --- a/references/tables.mdx +++ b/references/tables.mdx @@ -595,7 +595,9 @@ The order that the fields are listed in `default_show_underlying_values` is the Use `default_filters` to define filters on Dimensions that will be applied when no other user-defined filter on those Dimensions exists. Default filters will apply to tables on load and can be populated with a pre-determined value. Use them to suggest to users the kind of filters they might want to consider, or provide a default filtered view of a table that can be changed if needed. -An optional `required` flag can be added - in which case the filter _cannot_ be removed. This can be particularly useful if you have a large table and want to force users to filter on a partitioned date. +An optional `required` flag can be added, and if this flag is set to `required: true`, the filter for this field cannot be removed from the UI but users can still modify the operator and value to adjust how this filter is applied to the data. This ensures the filter is always applied in some form, while giving users flexibility to change the date range or other values. This can be particularly useful if you have a large table and want to force users to filter on a partitioned date. + +In contrast, when `required: false` (or omitted), the filter is pre-populated but fully editable — users can change the field, operator, value, or remove it entirely. Below you can see there is a default filter with the optional required flag, that will have show the last 14 days of data by default. @@ -652,10 +654,6 @@ Below you can see there is a default filter with the optional required flag, tha - When a filter has `required: true`, the filter cannot be removed from the UI, and the field cannot be changed. However, users can still modify the operator and value to adjust the filter as needed. This ensures the filter is always applied while giving users flexibility to change the date range or other values. - - In contrast, when `required: false` (or omitted), the filter is pre-populated but fully editable — users can change the field, operator, value, or remove it entirely. - Note: Required filters are not a security feature. For secure data access control, use [user attributes](/references/user-attributes).