Configure JINJA_FILTERS from DataBackend #1012

New Issue

MrUnknownDE · 2026-04-05T19:48:11+02:00

MrUnknownDE commented

2026-04-05 19:48:11 +02:00

Originally created by @anshulkamath on 10/21/2025

NetBox version

v4.4.4

Feature type

Change to existing functionality

Proposed functionality

Netbox provides the ability to enrich the Jinja execution environment with statically defined filters. This FR proposes the ability to load these filters dynamically via a DataBackend, like Git, S3, or local storage.

This ideally requires minimal lift; all that should be required is to maintain a registry of Jinja filters. The current implementation already sets the environment just-in-time for the rendering; a live registry sourced from a backend simply makes this dynamic.

Use case

This feature allows Netbox users to quickly write powerful configuration templates. Currently, a restart is required to render a template with a new filter. This significantly slows down iteration loops and is an obstacle to leveraging the data model to write rich, concise, device configurations.

Database changes

There should be no changes to the data model. All that is required is the ability to pull from a backend and load a refresh a live registry. These primitives should already be implemented for things like custom scripts.

External dependencies

As stated above, these primitives should already be implemented via the DataBackend.

*Originally created by @anshulkamath on 10/21/2025* ### NetBox version v4.4.4 ### Feature type Change to existing functionality ### Proposed functionality Netbox provides the ability to enrich the Jinja execution environment with [statically defined filters](https://github.com/netbox-community/netbox/blob/main/netbox/utilities/jinja2.py#L69). This FR proposes the ability to load these filters dynamically via a DataBackend, like Git, S3, or local storage. This ideally requires minimal lift; all that _should_ be required is to maintain a registry of Jinja filters. The current implementation already sets the environment just-in-time for the rendering; a live registry sourced from a backend simply makes this dynamic. ### Use case This feature allows Netbox users to quickly write powerful configuration templates. Currently, a restart is required to render a template with a new filter. This significantly slows down iteration loops and is an obstacle to leveraging the data model to write rich, concise, device configurations. ### Database changes There should be no changes to the data model. All that is required is the ability to pull from a backend and load a refresh a live registry. These primitives should already be implemented for things like custom scripts. ### External dependencies As stated above, these primitives should already be implemented via the `DataBackend`.

MrUnknownDE closed this issue

2026-04-05 19:48:11 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

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

No Label type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#1012