starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Replace references to ContentType without ObjectType proxy model & standardize field names #9296

New Issue
Closed
opened 2025-12-29 20:48:03 +01:00 by adam · 0 comments
adam commented 2025-12-29 20:48:03 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Feb 26, 2024).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.7.3

Feature type

Change to existing functionality

Proposed functionality

This proposal seeks to standardize the manner in which NetBox models reference Django's content types in two ways:

  1. Swap out all non-GFK references to contenttypes.ContentType in model definitions with core.ObjectType. This is a proxy model which exists to accommodate a custom manager. (ForeignKeys to ContentType which are employed as part of a GenericForeignKey should be left as-is.)
  2. Rename all existing model fields named content_type (ForeignKeys) or content_types (ManyToManyFields) to object_type or object_types, respectively. Applicable fields are listed below.

This will result in breaking changes to the REST and GraphQL APIs.

Fields to be Updated

Model Field Type
extras.Tag object_types M2M
users.ObjectPermission object_types M2M

Fields to be Renamed

Model Field Type
extras.CustomField content_types M2M
extras.CustomLink content_types M2M
extras.EventRule content_types M2M
extras.ExportTemplate content_types M2M
extras.ImageAttachment content_type FK
extras.SavedFilter content_types M2M
tenancy.ContactAssignment content_type FK

Additionally, we may want to rename the current object_type (singular) field on the CustomField model to prevent confusion with the proposed object_types (plural) field.

Use case

The primary goal of this proposal is to standardize the terminology we use when referencing object types in NetBox. In older models (those listed above), this relation is generally named "content type," whereas in new models we use the preferred term "object type." For reference, there are current seven "content type" fields and 14 fields named "object type" or a similar deviation. Standardizing these names avoids requiring an API consumer to recall which term is used for which model.

A secondary goal of this proposal is to update these foreign key and many-to-many relationships to reference our custom ObjectType model, which serves as a proxy for Django's stock ContentType model. Although this provides little immediate benefit, it eases the introduction of potential future features and simplifies the auditing of object type relationships.

Database changes

The PostgreSQL table columns corresponding to the seven fields listed above will be renamed as described. Schema migrations will also be created/updated to reflect the change in relationship from ContentType to ObjectType, however these will not effect any modifications to the underlying database as ObjectType is a proxy model for ContentType.

External dependencies

None

Originally created by @jeremystretch on GitHub (Feb 26, 2024). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.7.3 ### Feature type Change to existing functionality ### Proposed functionality This proposal seeks to standardize the manner in which NetBox models reference Django's [content types](https://docs.djangoproject.com/en/5.0/ref/contrib/contenttypes/) in two ways: 1. Swap out all non-GFK references to `contenttypes.ContentType` in model definitions with `core.ObjectType`. This is a proxy model which exists to accommodate a custom manager. (ForeignKeys to ContentType which are employed as part of a GenericForeignKey should be left as-is.) 2. Rename all existing model fields named `content_type` (ForeignKeys) or `content_types` (ManyToManyFields) to `object_type` or `object_types`, respectively. Applicable fields are listed below. **This will result in breaking changes** to the REST and GraphQL APIs. #### Fields to be Updated | Model | Field | Type | |--------------------------|----------------|------| | `extras.Tag` | `object_types` | M2M | | `users.ObjectPermission` | `object_types` | M2M | #### Fields to be Renamed | Model | Field | Type | |-----------------------------|-----------------|------| | `extras.CustomField` | `content_types` | M2M | | `extras.CustomLink` | `content_types` | M2M | | `extras.EventRule` | `content_types` | M2M | | `extras.ExportTemplate` | `content_types` | M2M | | `extras.ImageAttachment` | `content_type` | FK | | `extras.SavedFilter` | `content_types` | M2M | | `tenancy.ContactAssignment` | `content_type` | FK | Additionally, we may want to rename the _current_ `object_type` (singular) field on the CustomField model to prevent confusion with the proposed `object_types` (plural) field. ### Use case The primary goal of this proposal is to standardize the terminology we use when referencing object types in NetBox. In older models (those listed above), this relation is generally named "content type," whereas in new models we use the preferred term "object type." For reference, there are current seven "content type" fields and 14 fields named "object type" or a similar deviation. Standardizing these names avoids requiring an API consumer to recall which term is used for which model. A secondary goal of this proposal is to update these foreign key and many-to-many relationships to reference our custom ObjectType model, which serves as a proxy for Django's stock ContentType model. Although this provides little immediate benefit, it eases the introduction of potential future features and simplifies the auditing of object type relationships. ### Database changes The PostgreSQL table columns corresponding to the seven fields listed above will be renamed as described. Schema migrations will also be created/updated to reflect the change in relationship from ContentType to ObjectType, however these will not effect any modifications to the underlying database as ObjectType is a proxy model for ContentType. ### External dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 20:48:03 +01:00
adam closed this issue 2025-12-29 20:48:03 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#9296
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?