User configurable default filters for tables #5916

New Issue

adam · 2025-12-29T19:34:11+01:00

adam commented

2025-12-29 19:34:11 +01:00

Originally created by @jasonyates on GitHub (Jan 10, 2022).

NetBox version

3.1.5

Feature type

New functionality

Proposed functionality

Allow the Netbox administrator and/or logged in user to configure default filters for tables.

This could link with #7759

Use case

In some situations it could be beneficial to have administrator defined (or user defined) default filters for certain tables. My use case specifically is with Circuits. We recently migrated all of our circuit data from an in-house tool over to Netbox including historical data. As it stands, we have 300+ circuits however only ~150 are currently active. 9/10 I'm only looking in Netbox for active circuit information so it would be useful to have a default filter applied to that table to only show Active circuits.

Database changes

No response

External dependencies

No response

Originally created by @jasonyates on GitHub (Jan 10, 2022). ### NetBox version 3.1.5 ### Feature type New functionality ### Proposed functionality Allow the Netbox administrator and/or logged in user to configure default filters for tables. This could link with #7759 ### Use case In some situations it could be beneficial to have administrator defined (or user defined) default filters for certain tables. My use case specifically is with Circuits. We recently migrated all of our circuit data from an in-house tool over to Netbox including historical data. As it stands, we have 300+ circuits however only ~150 are currently active. 9/10 I'm only looking in Netbox for active circuit information so it would be useful to have a default filter applied to that table to only show Active circuits. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature label 2025-12-29 19:34:11 +01:00

adam closed this issue

2025-12-29 19:34:11 +01:00

adam commented

2025-12-29 19:34:11 +01:00

@sdktr commented on GitHub (Jan 11, 2022):

Related to userfavorites https://github.com/netbox-community/netbox/issues/8248 ?

@sdktr commented on GitHub (Jan 11, 2022): Related to userfavorites https://github.com/netbox-community/netbox/issues/8248 ?

adam commented

2025-12-29 19:34:12 +01:00

@jeremystretch commented on GitHub (Jan 14, 2022):

Allow the Netbox administrator and/or logged in user to configure default filters for tables.

I find it difficult to imagine the workflow for this. For example, what happens if a user clears any applied filters? Would that clear all filters, or would it restore their default set? How would you distinguish between the two.

Maybe instead of having a default, we could allow users to define and save filter presets, and NetBox would just remember the last-used preset. I'm not sure exactly what a preset would look like, but it would really only need to map a user and object type to a JSON dict of applied filters, with a descriptive name. If this sounds reasonable I can put some more thought into it and open a new FR.

@jeremystretch commented on GitHub (Jan 14, 2022): > Allow the Netbox administrator and/or logged in user to configure default filters for tables. I find it difficult to imagine the workflow for this. For example, what happens if a user clears any applied filters? Would that clear _all_ filters, or would it restore their default set? How would you distinguish between the two. Maybe instead of having a default, we could allow users to define and save filter presets, and NetBox would just remember the last-used preset. I'm not sure exactly what a preset would look like, but it would really only need to map a user and object type to a JSON dict of applied filters, with a descriptive name. If this sounds reasonable I can put some more thought into it and open a new FR.

adam commented

2025-12-29 19:34:12 +01:00

@jasonyates commented on GitHub (Jan 15, 2022):

I find it difficult to imagine the workflow for this. For example, what happens if a user clears any applied filters? Would that clear all filters, or would it restore their default set? How would you distinguish between the two.

In my mind if a user was to clear filters, it would clear them as opposed to restoring to the admin defined default. The intention isn't to stop users getting to data, it's to guide them to the most relevant data by pre-loading a filter.

Maybe instead of having a default, we could allow users to define and save filter presets, and NetBox would just remember the last-used preset. I'm not sure exactly what a preset would look like, but it would really only need to map a user and object type to a JSON dict of applied filters, with a descriptive name. If this sounds reasonable I can put some more thought into it and open a new FR.

This works too. Perhaps once you have a filter created, on the applied filters section the ability to save it as a default view (and clear it) would be a good first step. If there was the ability to save filters via the API too then I could leverage that to apply a filter for my users thus rending the "admin default" not required.

@jasonyates commented on GitHub (Jan 15, 2022): > I find it difficult to imagine the workflow for this. For example, what happens if a user clears any applied filters? Would that clear _all_ filters, or would it restore their default set? How would you distinguish between the two. In my mind if a user was to clear filters, it would clear them as opposed to restoring to the admin defined default. The intention isn't to stop users getting to data, it's to guide them to the most relevant data by pre-loading a filter. > Maybe instead of having a default, we could allow users to define and save filter presets, and NetBox would just remember the last-used preset. I'm not sure exactly what a preset would look like, but it would really only need to map a user and object type to a JSON dict of applied filters, with a descriptive name. If this sounds reasonable I can put some more thought into it and open a new FR. This works too. Perhaps once you have a filter created, on the applied filters section the ability to save it as a default view (and clear it) would be a good first step. If there was the ability to save filters via the API too then I could leverage that to apply a filter for my users thus rending the "admin default" not required.

adam commented

2025-12-29 19:34:12 +01:00

@jeremystretch commented on GitHub (Jan 15, 2022):

In my mind if a user was to clear filters, it would clear them as opposed to restoring to the admin defined default.

Right, but how would you convey that in the UI? For example, if I have a default filter set for sites and I navigate to /dcim/sites/, is it going to apply the default filter? If so, what query parameters would I specify to not apply the filter? I'd want to avoid doing anything to declare a negative (e.g. ?default_filter=False).

@jeremystretch commented on GitHub (Jan 15, 2022): > In my mind if a user was to clear filters, it would clear them as opposed to restoring to the admin defined default. Right, but how would you convey that in the UI? For example, if I have a default filter set for sites and I navigate to `/dcim/sites/`, is it going to apply the default filter? If so, what query parameters would I specify to _not_ apply the filter? I'd want to avoid doing anything to declare a negative (e.g. `?default_filter=False`).

adam commented

2025-12-29 19:34:12 +01:00

@jasonyates commented on GitHub (Jan 15, 2022):

Right, but how would you convey that in the UI? For example, if I have a default filter set for sites and I navigate to /dcim/sites/, is it going to apply the default filter? If so, what query parameters would I specify to not apply the filter? I'd want to avoid doing anything to declare a negative (e.g. ?default_filter=False).

Why would you need an option to not apply the filter with a query parameter? As a netbox administrator i'm trying to reduce some of the noise within the application for the majority of my users. In my example for the FR, the data we store around circuits is crucial and we have a genuine use case for keeping historical circuit data (billing disputes months after disconnect etc) but the number of people that need to access that historical data is small compared to our user base.

What i'm proposing is to allow me as an administrator of the system to define a default filter and have that automatically applied for all users when they first visit a table view e.g. /dcim/circuits/ - If a user wants to remove the filter to see all of the data they just clear it as they normally would had they defined it themselves e.g.

@jasonyates commented on GitHub (Jan 15, 2022): > Right, but how would you convey that in the UI? For example, if I have a default filter set for sites and I navigate to `/dcim/sites/`, is it going to apply the default filter? If so, what query parameters would I specify to _not_ apply the filter? I'd want to avoid doing anything to declare a negative (e.g. `?default_filter=False`). Why would you need an option to not apply the filter with a query parameter? As a netbox administrator i'm trying to reduce some of the noise within the application for the majority of my users. In my example for the FR, the data we store around circuits is crucial and we have a genuine use case for keeping historical circuit data (billing disputes months after disconnect etc) but the number of people that need to access that historical data is small compared to our user base. What i'm proposing is to allow me as an administrator of the system to define a default filter and have that automatically applied for all users when they first visit a table view e.g. /dcim/circuits/ - If a user wants to remove the filter to see all of the data they just clear it as they normally would had they defined it themselves e.g. <img width="578" alt="Screenshot 2022-01-15 at 09 30 38" src="https://user-images.githubusercontent.com/242483/149629665-369fad3c-9390-464e-8998-90fac44475e1.png">

adam commented

2025-12-29 19:34:12 +01:00

@Ryujn91 commented on GitHub (Jan 16, 2022):

I have a similar use / need for functionality like this.

Ours is specific to sites / devices. we have hundreds of branches but typically this is fairly static data so is not needed as often, however the DC's are much more dynamic. having a mechanism where when loading these pages it applies a default filter to display a specific site but users were still free to filter anyway they needed.

This just helps to remove noise from the off, i'm not sure how it would be implemented but just thought id second the desire to see such functionality.

@Ryujn91 commented on GitHub (Jan 16, 2022): I have a similar use / need for functionality like this. Ours is specific to sites / devices. we have hundreds of branches but typically this is fairly static data so is not needed as often, however the DC's are much more dynamic. having a mechanism where when loading these pages it applies a default filter to display a specific site but users were still free to filter anyway they needed. This just helps to remove noise from the off, i'm not sure how it would be implemented but just thought id second the desire to see such functionality.

adam commented

2025-12-29 19:34:13 +01:00

@github-actions[bot] commented on GitHub (Mar 18, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Mar 18, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:34:13 +01:00

@jeremystretch commented on GitHub (Apr 6, 2022):

Sorry, this fell off my radar.

Why would you need an option to not apply the filter with a query parameter?

Consider the screenshot above. Presumably, this is what the user sees when visiting /circuits/circuits/, without specifying any filters (because they've been defined as defaults). So what happens when they want to deactivate the default filter(s)? You can't just return to the default URL; you need some way to declare that the default filter should no longer be applied.

One solution would be to redirect the user to a URL with the default filters applied. For example, navigating to /circuits/circuits/ would return a 302 redirect pointing to /circuits/circuits/?status=active. I'm not sure if that would become problematic.

@jeremystretch commented on GitHub (Apr 6, 2022): Sorry, this fell off my radar. > Why would you need an option to not apply the filter with a query parameter? Consider the screenshot above. Presumably, this is what the user sees when visiting `/circuits/circuits/`, without specifying any filters (because they've been defined as defaults). So what happens when they want to deactivate the default filter(s)? You can't just return to the default URL; you need some way to declare that the default filter should no longer be applied. One solution would be to redirect the user to a URL with the default filters applied. For example, navigating to `/circuits/circuits/` would return a 302 redirect pointing to `/circuits/circuits/?status=active`. I'm not sure if that would become problematic.

adam commented

2025-12-29 19:34:13 +01:00

@github-actions[bot] commented on GitHub (Jun 7, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 7, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:34:13 +01:00

@UlrikNN commented on GitHub (Jun 22, 2022):

Hi, We would love this functionality :) We are looking to keep our history in the database by tagging deleted/scrapped items as "Deleted" A default, user clearable filter would ensure thet a user normally sees "live" stuff but still can show historical entities when need arises. Hope this posting avoids the "pending closure" status ;)

Looking forward to any responses!

@UlrikNN commented on GitHub (Jun 22, 2022): Hi, We would love this functionality :) We are looking to keep our history in the database by tagging deleted/scrapped items as "Deleted" A default, user clearable filter would ensure thet a user normally sees "live" stuff but still can show historical entities when need arises. Hope this posting avoids the "pending closure" status ;) Looking forward to any responses!

adam commented

2025-12-29 19:34:14 +01:00

@jeremystretch commented on GitHub (Jun 28, 2022):

IMO #9623 (also opened by @jasonyates) is a more preferable approach to this use case, as it would likely be less error-prone.

@jeremystretch commented on GitHub (Jun 28, 2022): IMO #9623 (also opened by @jasonyates) is a more preferable approach to this use case, as it would likely be less error-prone.

adam commented

2025-12-29 19:34:14 +01:00

@jeremystretch commented on GitHub (Jul 7, 2022):

I'm going to close this FR in favor of #9623, both for the implementation problem I cited above and because IMO the proposal in #9623 would be more powerful.

@jeremystretch commented on GitHub (Jul 7, 2022): I'm going to close this FR in favor of #9623, both for the implementation problem I cited above and because IMO the proposal in #9623 would be more powerful.

Sign in to join this conversation.

Branches Tags

main

21102-fix-graphiql-explorer

update-changelog-comments-docs

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#5916