Prevent more lookup expressions in filterset items from "disabling" url filtering #11771

New Issue

adam · 2025-12-29T21:49:41+01:00

adam commented

2025-12-29 21:49:41 +01:00

Originally created by @mwobst on GitHub (Oct 24, 2025).

NetBox version

v4.4.1

Feature type

Change to existing functionality

Proposed functionality

Might also be a bug, but that form is not really fitting … no real textarea for explaining stuff.

Anyway, the headline could be confusing. As an example the RackTypeFilterSet. In serial = MultiValueCharFilter(lookup_expr='iexact'), modify the value of lookup_expr to icontains. Now you could search for a rack with ?serial=ABCDEF by using ?serial=bcd in the URL. But serial__ie=abcdef won’t work. In fact, that search part is ignored altogether.

Same with NumberFilter. Take RackTypeFilterSet, starting_unit. Add lookup_expr='lte' to starting_unit = django_filters.NumberFilter(). Now ?starting_unit=3 will include rack types with starting unit = 3 or lower, but ?starting_unit__gte=3 is simply ignored; all racks are displayed.

Reason

in netbox/filtersets.py, the following is defined:

STANDARD_LOOKUPS = (
    'exact',
    'iexact',
    'in',
    'contains',
)

Later in the code, this tuple is used to force an early return out of a method if the used lookup expression is not in the tuple which seems to prevent any URL filtering with stuff like __ie and so on. 'contains' has been added quite recently, probably due the "Loose Filtering" of custom fields.

Proposal

I would like to add at least the following items:

'icontains'
'startswith'
'istartswith'
'endswith'
'iendswith'
'regex'
'iregex'
'gt'
'gte'
'lt'
'lte'

That change is as simple as it can get and it shouldn’t™ break or even change anything at all. If anything, it simply allows plugin developers a little bit more freedom. I can submit a PR myself, if this proposal is okay.

(And I’m aware that this is quite specific and probably occurs very rarely, but still … it seems unnecesarily limitting)

Use case

Have a filterset field that shall use 'icontains' as a lookup expression, but you still want to use the iexact search. NetBox in its core doesn’t seem to do this. There is the general search (?q=…) that usually applies icontains, and then there are a multitude of specific search that require the (i)exact values.

Of course one could say: Just use the URL, but that is more cumbersome for GUI users.

Database changes

None at all.

External dependencies

None

Originally created by @mwobst on GitHub (Oct 24, 2025). ### NetBox version v4.4.1 ### Feature type Change to existing functionality ### Proposed functionality Might also be a bug, but that form is not really fitting … no real textarea for explaining stuff. Anyway, the headline could be confusing. As an example the RackTypeFilterSet. In `serial = MultiValueCharFilter(lookup_expr='iexact')`, modify the value of `lookup_expr` to `icontains`. Now you could search for a rack with `?serial=ABCDEF` by using ?serial=bcd in the URL. But `serial__ie=abcdef` won’t work. In fact, that search part is ignored altogether. Same with NumberFilter. Take RackTypeFilterSet, starting_unit. Add `lookup_expr='lte'` to `starting_unit = django_filters.NumberFilter()`. Now `?starting_unit=3` will include rack types with starting unit = 3 or lower, but `?starting_unit__gte=3` is simply ignored; all racks are displayed. **Reason** in netbox/filtersets.py, the following is defined: ``` STANDARD_LOOKUPS = ( 'exact', 'iexact', 'in', 'contains', ) ``` Later in the code, this tuple is used to force an early return out of a method if the used lookup expression is not in the tuple which seems to prevent any URL filtering with stuff like `__ie` and so on. 'contains' has been added quite recently, probably due the "Loose Filtering" of custom fields. **Proposal** I would like to add at least the following items: - 'icontains' - 'startswith' - 'istartswith' - 'endswith' - 'iendswith' - 'regex' - 'iregex' - 'gt' - 'gte' - 'lt' - 'lte' That change is as simple as it can get and it shouldn’t™ break or even change anything at all. If anything, it simply allows plugin developers a little bit more freedom. I can submit a PR myself, if this proposal is okay. (And I’m aware that this is quite specific and probably occurs very rarely, but still … it seems unnecesarily limitting) ### Use case Have a filterset field that shall use 'icontains' as a lookup expression, but you still want to use the iexact search. NetBox in its core doesn’t seem to do this. There is the general search (?q=…) that usually applies icontains, and then there are a multitude of specific search that require the (i)exact values. Of course one could say: Just use the URL, but that is more cumbersome for GUI users. ### Database changes None at all. ### External dependencies None

adam added the type: feature status: backlog labels 2025-12-29 21:49:41 +01:00

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11771