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

Standardize on naming for ContentType fields #3744

New Issue
Closed
opened 2025-12-29 18:30:52 +01:00 by adam · 2 comments
adam commented 2025-12-29 18:30:52 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Jun 3, 2020).

Proposed Changes

Update models in NetBox to use a standardized name for ForeignKey fields to the ContentType model. The name object_type is most appropriate IMO. Applicable fields include:

  • dcim.Cable
    • termination_a_type
    • termination_b_type
  • extras.CustomField
    • obj_type
  • extras.CustomFieldValue
    • obj_type
  • extras.CustomLink
    • content_type
  • extras.ExportTemplate
    • content_type
  • extras.Graph
    • type
  • extras.ImageAttachment
    • content_type
  • extras.ObjectChange
    • changed_object_type
    • related_object_type
  • extras.Webhook
    • obj_type
  • users.ObjectPermission
    • content_types (v2.9)

The proposal here is to rename fields named type, obj_type, or content_type to object_type. The Cable and ObjectChange models likely need no changes.

Justification

  • Standardizing on a common name readily conveys the purpose of the field.
  • object_type is more accurate than content_type and more apparent than obj_type. (type alone should be avoided due to its status as a reserved word in Python.)
Originally created by @jeremystretch on GitHub (Jun 3, 2020). ### Proposed Changes Update models in NetBox to use a standardized name for ForeignKey fields to the ContentType model. The name `object_type` is most appropriate IMO. Applicable fields include: * dcim.Cable * termination_a_type * termination_b_type * ~extras.CustomField~ * ~obj_type~ * ~extras.CustomFieldValue~ * ~obj_type~ * extras.CustomLink * content_type * extras.ExportTemplate * content_type * ~extras.Graph~ * ~type~ * extras.ImageAttachment * content_type * extras.ObjectChange * changed_object_type * related_object_type * extras.Webhook * obj_type * users.ObjectPermission * content_types (v2.9) The proposal here is to rename fields named `type`, `obj_type`, or `content_type` to `object_type`. The Cable and ObjectChange models likely need no changes. ### Justification * Standardizing on a common name readily conveys the purpose of the field. * `object_type` is more accurate than `content_type` and more apparent than `obj_type`. (`type` alone should be avoided due to its status as a reserved word in Python.)
adam added the status: acceptedtype: housekeeping labels 2025-12-29 18:30:52 +01:00
adam closed this issue 2025-12-29 18:30:52 +01:00
adam commented 2025-12-29 18:30:53 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 21, 2020):

My view:

Standardization is good, where we can get away with it. I know there are going to be places where we can (ObjectPermissions) but we can get close.

I would be worried however about how many instances we call the object_type (or the others) directly. I don't think there is many but could be wrong.

@DanSheps commented on GitHub (Sep 21, 2020): My view: Standardization is good, where we can get away with it. I know there are going to be places where we can (ObjectPermissions) but we can get close. I would be worried however about how many instances we call the object_type (or the others) directly. I don't think there is many but could be wrong.
adam commented 2025-12-29 18:30:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 14, 2020):

Thought about this some more. Seems fine to just change obj_type on CustomField and Webhook to content_types, since these are ManyToManyFields. We can leave the rest as they are.

@jeremystretch commented on GitHub (Oct 14, 2020): Thought about this some more. Seems fine to just change `obj_type` on CustomField and Webhook to `content_types`, since these are ManyToManyFields. We can leave the rest as they are.
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: housekeeping
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#3744
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?