Saved Filters

[jasonyates]

NetBox version

3.2.5

Feature type

New functionality

Proposed functionality

After building a filter it would be useful to be able to save it for future re-use, give it a name and the option to make it public. Public filters would then be viewable by all logged in to Netbox.

Proposing a 3rd tab alongside Results | Filters - perhaps 'Saved Filters'. Or possibly a section within the existing Filters tab to show any saved filters.

UI Suggestion for model list view

Filters would not need to be modifiable, once saved, the user that created the filter can delete it from the saved filters list. When a user is removed from the system, the filters they created should also be removed.

Use case

I often find myself having to build the same filter repeatedly in Netbox as well as having to remember to share links with the team when I build a useful filter. Having the option to save a filter in Netbox and share it with my users would save time.

Database changes

A new model would need to be created to store the saved filters. Model would require a relation to the object type e.g. dcim.devices, filter attributes, friendly name, is public and a relation to the user that created it (to allow that user to delete it).

External dependencies

No response

[jeremystretch]

@jasonyates it sounds like a neat idea, but could you spend some more time fleshing out the proposal please? You haven't noted anything under database changes, and I'd assume this would require at least a new model.

[jasonyates]

@jeremystretch Done. I included a proposed mockup of a piece of the UI too.

[jeremystretch]

Expanding on the proposed model a bit, we probably need:

• Name
• User (nullable FK)
• Description (optional)
• Object type(s?)
• Query parameters (JSON data)
• Shared (boolean)

If shared is true, the filter will be made available for other users; otherwise, only the owner will see it listed as an available option when filtering an object list. However, it should still appear as visible in the saved filters list.

I've proposed making the user field nullable, so that the saved filter remains intact if the owning user is deleted.

We still need to determine how a saved filter would be applied in practice. I see two options:

• Reference the saved filter directly when making a query, e.g. GET /dcim/sites/?filter=my_saved_filter
• Use the filter to generate a query URL in the UI, so that when the user clicks "My saved filter," a request is made for e.g. GET /dcim/sites/?status=planned&tenant=blah

There are some caveats to both approaches. Making reference to a filter doesn't reveal the actual query parameters being used, which is likely to lead to confusion. It might also be difficult to parse on the backend. However, the second approach is of very limited utility outside of the UI: It provides no way for an API client to directly employ a saved filter.

A third, hybrid approach might be reasonable: A request for e.g. GET /dcim/sites/?filter=my_saved_filter would return a 302 redirect with the appropriate query parameters attached. This is slightly less efficient but may be a reasonable compromise.