Replace references to ContentType without ObjectType proxy model & standardize field names #15277
Labels
status: accepted
This issue has been accepted for implementation
type: feature
Introduction of new functionality to the application
Milestone
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:
contenttypes.ContentType
in model definitions withcore.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.)content_type
(ForeignKeys) orcontent_types
(ManyToManyFields) toobject_type
orobject_types
, respectively. Applicable fields are listed below.This will result in breaking changes to the REST and GraphQL APIs.
Fields to be Updated
extras.Tag
object_types
users.ObjectPermission
object_types
Fields to be Renamed
extras.CustomField
content_types
extras.CustomLink
content_types
extras.EventRule
content_types
extras.ExportTemplate
content_types
extras.ImageAttachment
content_type
extras.SavedFilter
content_types
tenancy.ContactAssignment
content_type
Additionally, we may want to rename the current
object_type
(singular) field on the CustomField model to prevent confusion with the proposedobject_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
The text was updated successfully, but these errors were encountered: