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

[jeremystretch]

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