Support the use of NetBox features by plugin models #5969

New Issue

adam · 2025-12-29T19:35:01+01:00

adam commented

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

Originally created by @jeremystretch on GitHub (Jan 19, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.1.6

Feature type

New functionality

Proposed functionality

Officially support the use of various NetBox features by plugin models. These include:

Custom fields
Custom links
Custom validation
Export Templates
Journaling
Tags
Webhooks

For each feature above, we should introduce (or repurpose) a class which a model can inherit to enable the feature. For example, a TagsMixin class would enable the assignment of tags, and a CustomLinksMixin would enable custom links.

In the interest of cleanliness, we probably also want to introduce a base model class (e.g. BaseModel) that inherits all such feature mixins. A plugin model can then simply inherit from BaseModel to enable all features (while reserving the option to inherit only specific mixin classes if only a subset of features is desired).

I'd like to do away with the extras_features() decorator that's currently used to register features for specific models, as it's redundant for features which require additional fields or attributes on the model (see #8373). We may be able to leverage Django's class_prepared signal to automate this process.

Use case

This initiative will enable plugin authors to make use of many valuable features built into NetBox in a convenient and supported way.

Database changes

No response

External dependencies

No response

Originally created by @jeremystretch on GitHub (Jan 19, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.1.6 ### Feature type New functionality ### Proposed functionality Officially support the use of various NetBox features by plugin models. These include: * Custom fields * Custom links * Custom validation * Export Templates * Journaling * Tags * Webhooks For each feature above, we should introduce (or repurpose) a class which a model can inherit to enable the feature. For example, a TagsMixin class would enable the assignment of tags, and a CustomLinksMixin would enable custom links. In the interest of cleanliness, we probably also want to introduce a base model class (e.g. BaseModel) that inherits all such feature mixins. A plugin model can then simply inherit from BaseModel to enable all features (while reserving the option to inherit only specific mixin classes if only a subset of features is desired). I'd like to do away with the `extras_features()` decorator that's currently used to register features for specific models, as it's redundant for features which require additional fields or attributes on the model (see #8373). We may be able to leverage Django's [`class_prepared` signal](https://docs.djangoproject.com/en/stable/ref/signals/#class-prepared) to automate this process. ### Use case This initiative will enable plugin authors to make use of many valuable features built into NetBox in a convenient and supported way. ### Database changes _No response_ ### External dependencies _No response_

adam added the status: accepted type: feature topic: plugins labels 2025-12-29 19:35:01 +01:00

adam closed this issue

2025-12-29 19:35:02 +01:00

adam commented

2025-12-29 19:35:02 +01:00

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

I've made good progress with this already. Ditched the extras_features() decorator entirely, and refactored the base model classes. Still have some work to do, but I'm very encouraged by the results so far.

As this is the first major extension of the plugins framework since its introduction, I'm also going to be working on rebuilding the documentation. I've enlisted mkdocstrings for code introspection, which will help immensely. A rough working example is below.

@jeremystretch commented on GitHub (Jan 19, 2022): I've made good progress with this already. Ditched the `extras_features()` decorator entirely, and refactored the base model classes. Still have some work to do, but I'm very encouraged by the results so far. As this is the first major extension of the plugins framework since its introduction, I'm also going to be working on rebuilding the documentation. I've enlisted [mkdocstrings](https://mkdocstrings.github.io/) for code introspection, which will help immensely. A rough working example is below. ![Screenshot 2022-01-19 at 16-10-18 Model Features - NetBox Documentation](https://user-images.githubusercontent.com/13487278/150215132-7aeca382-2c68-4029-9eba-cfb5546b9468.png)

adam commented

2025-12-29 19:35:03 +01:00

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

Extended the list above to include custom validation, and remove job results as a default feature.

@jeremystretch commented on GitHub (Jan 20, 2022): Extended the list above to include custom validation, and remove job results as a default feature.

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