Plugin Version
0.5.1
Proposed functionality
Custom Objects should be accessible inside NetBox device configuration templates, which are rendered with Jinja2.
Two access patterns should be supported:
Attribute-style namespace (context injection):
{% for iface in custom_objects.OSPFInterface.filter(device=device) %}
interface {{ iface.name }}
ip ospf area {{ iface.area }}
{% endfor %}Filter syntax:
{% for iface in 'OSPFInterface' | custom_objects %}
interface {{ iface.name }}
{% endfor %}Both patterns resolve the Custom Object Type by name at render time, so templates remain valid even if internal IDs change.
The implementation will use the jinja2_filters plugin hook and get_jinja2_context() method introduced in NetBox core PR #22363 (targeting NetBox 4.7). On NetBox versions that do not yet include those hooks, the plugin degrades gracefully: an informational message is logged at startup and the custom_objects identifier is simply unavailable in templates — no crash, no silent wrong output.
Use case
Device configuration templates today can reference NetBox's built-in models (devices, interfaces, IP addresses, etc.) but have no way to reach plugin-managed data. Custom Objects are commonly used to model routing protocol parameters, circuit details, or site-specific attributes that belong in rendered device configs — for example OSPF interface costs, BGP peer groups, or MPLS label ranges. Without this feature, operators must duplicate that data in custom fields or work around it with external scripts.
External dependencies
Requires NetBox 4.7+ (with netbox-community/netbox#22363 merged) for full functionality. The plugin will continue to install and operate normally on NetBox 4.5/4.6; config template integration is simply inactive on those versions and documented as such.
Plugin Version
0.5.1
Proposed functionality
Custom Objects should be accessible inside NetBox device configuration templates, which are rendered with Jinja2.
Two access patterns should be supported:
Attribute-style namespace (context injection):
Filter syntax:
Both patterns resolve the Custom Object Type by name at render time, so templates remain valid even if internal IDs change.
The implementation will use the
jinja2_filtersplugin hook andget_jinja2_context()method introduced in NetBox core PR #22363 (targeting NetBox 4.7). On NetBox versions that do not yet include those hooks, the plugin degrades gracefully: an informational message is logged at startup and thecustom_objectsidentifier is simply unavailable in templates — no crash, no silent wrong output.Use case
Device configuration templates today can reference NetBox's built-in models (devices, interfaces, IP addresses, etc.) but have no way to reach plugin-managed data. Custom Objects are commonly used to model routing protocol parameters, circuit details, or site-specific attributes that belong in rendered device configs — for example OSPF interface costs, BGP peer groups, or MPLS label ranges. Without this feature, operators must duplicate that data in custom fields or work around it with external scripts.
External dependencies
Requires NetBox 4.7+ (with netbox-community/netbox#22363 merged) for full functionality. The plugin will continue to install and operate normally on NetBox 4.5/4.6; config template integration is simply inactive on those versions and documented as such.