Store feature flags directly on ObjectType model #11402

New Issue

adam · 2025-12-29T21:44:47+01:00

adam commented

2025-12-29 21:44:47 +01:00

Originally created by @jeremystretch on GitHub (Jul 21, 2025).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v4.3.4

Feature type

Change to existing functionality

Proposed functionality

Convert ObjectType from a proxy model to a concrete model inheriting from Django's native ContentType model, and add boolean fields to indicate the presence or absence of support for all well-known model features.

A draft of the updated model definition is below:

class ObjectType(ContentType):
    feature_bookmarks = models.BooleanField()
    feature_change_logging = models.BooleanField()
    feature_cloning = models.BooleanField()
    feature_contacts = models.BooleanField()
    feature_custom_fields = models.BooleanField()
    # ...

    # Retain the current manager
    objects = ObjectTypeManager()

    class Meta:
        verbose_name = _('object type')
        verbose_name_plural = _('object types')

The ObjectTypeManager will then be updated to query on these feature flags directly, rather than interrogating the in-memory registry to determine which features are supported for a model. The signature for querying ObjectTypes by feature within NetBox core and plugins will remain unchanged, e.g. ObjectType.objects.with_feature('event_rules') will still work as before.

The current, complex logic (below) constructs a query matching against all models listed in the registry as supporting a given feature:

q = Q()
for app_label, models in registry['model_features'][feature].items():
    q |= Q(app_label=app_label, model__in=models)
return self.get_queryset().filter(q)

This new approach simplifies the necessary query substantially:

field_name = f'feature_{feature}'
return self.get_queryset().filter(**{field_name: True})

Use case

Feature support for individual models is currently mapped in the application registry, which is compiled at initialization time and considered immutable. As the registry is maintained in isolation from other processes, this approach prohibits the dynamic creation of modifications of models at runtime in plugins, namely netbox-custom-objects.

Moving these feature flags from the in-memory registry to the database removes this limitation, as any new models or changes to existing models are immediately replicated to peer processes by way of updating the PostgreSQL database. This change also affords a much more performant means of querying models by feature, as we can now issue simple boolean queries and avoid complex queries based on app_label and model (name).

Database changes

Convert ObjectType to a concrete model, which will result in the creation of a new core_objecttype table
Add a boolean field on this model to represent each supported NetBox feature

External dependencies

N/A

Originally created by @jeremystretch on GitHub (Jul 21, 2025). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v4.3.4 ### Feature type Change to existing functionality ### Proposed functionality Convert ObjectType from a proxy model to a concrete model inheriting from Django's native ContentType model, and add boolean fields to indicate the presence or absence of support for all well-known [model features](https://netboxlabs.com/docs/netbox/plugins/development/models/#enabling-netbox-features). A draft of the updated model definition is below: ```python class ObjectType(ContentType): feature_bookmarks = models.BooleanField() feature_change_logging = models.BooleanField() feature_cloning = models.BooleanField() feature_contacts = models.BooleanField() feature_custom_fields = models.BooleanField() # ... # Retain the current manager objects = ObjectTypeManager() class Meta: verbose_name = _('object type') verbose_name_plural = _('object types') ``` The `ObjectTypeManager` will then be updated to query on these feature flags directly, rather than interrogating the in-memory registry to determine which features are supported for a model. The signature for querying ObjectTypes by feature within NetBox core and plugins will remain unchanged, e.g. `ObjectType.objects.with_feature('event_rules')` will still work as before. The current, complex logic (below) constructs a query matching against _all_ models listed in the registry as supporting a given feature: ```python q = Q() for app_label, models in registry['model_features'][feature].items(): q |= Q(app_label=app_label, model__in=models) return self.get_queryset().filter(q) ``` This new approach simplifies the necessary query substantially: ```python field_name = f'feature_{feature}' return self.get_queryset().filter(**{field_name: True}) ``` ### Use case Feature support for individual models is currently mapped in the application registry, which is compiled at initialization time and considered immutable. As the registry is maintained in isolation from other processes, this approach prohibits the dynamic creation of modifications of models at runtime in plugins, namely [netbox-custom-objects](https://github.com/netboxlabs/netbox-custom-objects). Moving these feature flags from the in-memory registry to the database removes this limitation, as any new models or changes to existing models are immediately replicated to peer processes by way of updating the PostgreSQL database. This change also affords a much more performant means of querying models by feature, as we can now issue simple boolean queries and avoid complex queries based on `app_label` and `model` (name). ### Database changes - Convert ObjectType to a concrete model, which will result in the creation of a new `core_objecttype` table - Add a boolean field on this model to represent each supported NetBox feature ### External dependencies N/A

adam added the status: accepted type: feature complexity: medium labels 2025-12-29 21:44:47 +01:00

adam closed this issue

2025-12-29 21:44:47 +01:00

Sign in to join this conversation.

Branches Tags

main

21142-device-component-graphql-filters

21050-device-oob-ip-may-become-orphaned

21102-fix-graphiql-explorer

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