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

Omit internal fields from change logs #3368

New Issue
Closed
opened 2025-12-29 18:28:25 +01:00 by adam · 7 comments
adam commented 2025-12-29 18:28:25 +01:00
Owner
Copy Link

Originally created by @hSaria on GitHub (Feb 21, 2020).

Proposed Changes

Omit private/internal model fields from change logs. The current list of private fields:

  • _name: used for ordering
  • (dcim.Interface) _connected_circuittermination, _connected_interface: unsure if they're meant to be visible in the change logs
  • (dcim.Region) level, lft, rght, tree_id: the MPTT fields
  • (dcim.Cable) _abs_length, _termination_a_device, _termination_b_device: normalization/caching

Justification

The fields do not serve any purpose outside of NetBox. By removing them from the change logs, they will look more readable to a user. This idea surfaced in https://github.com/netbox-community/netbox/issues/4183#issuecomment-587141060.

Originally created by @hSaria on GitHub (Feb 21, 2020). ### Proposed Changes Omit private/internal model fields from change logs. The current list of private fields: * `_name`: used for ordering * (`dcim.Interface`) `_connected_circuittermination`, `_connected_interface`: unsure if they're meant to be visible in the change logs * (`dcim.Region`) `level`, `lft`, `rght`, `tree_id`: the MPTT fields * (`dcim.Cable`) `_abs_length`, `_termination_a_device`, `_termination_b_device`: normalization/caching ### Justification The fields do not serve any purpose outside of NetBox. By removing them from the change logs, they will look more readable to a user. This idea surfaced in https://github.com/netbox-community/netbox/issues/4183#issuecomment-587141060.
adam added the status: acceptedtype: feature labels 2025-12-29 18:28:25 +01:00
adam closed this issue 2025-12-29 18:28:25 +01:00
adam commented 2025-12-29 18:28:25 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 21, 2020):

Here's an example of how a region's change log would benefit from this.

Before

{
    "created": "2020-02-10",
    "last_updated": "2020-02-10T13:19:37.319Z",
    "level": 0,
    "lft": 1,
    "name": "'murica",
    "parent": null,
    "rght": 2,
    "slug": "murica",
    "tree_id": 2
}

After

{
    "created": "2020-02-10",
    "last_updated": "2020-02-10T13:19:37.319Z",
    "name": "'murica",
    "parent": null,
    "slug": "murica"
}
@hSaria commented on GitHub (Feb 21, 2020): Here's an example of how a region's change log would benefit from this. #### Before ```json { "created": "2020-02-10", "last_updated": "2020-02-10T13:19:37.319Z", "level": 0, "lft": 1, "name": "'murica", "parent": null, "rght": 2, "slug": "murica", "tree_id": 2 } ``` #### After ```json { "created": "2020-02-10", "last_updated": "2020-02-10T13:19:37.319Z", "name": "'murica", "parent": null, "slug": "murica" } ```
adam commented 2025-12-29 18:28:26 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Feb 21, 2020):

That make sense. I accept this

@kobayashi commented on GitHub (Feb 21, 2020): That make sense. I accept this
adam commented 2025-12-29 18:28:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

We need to devise a robust mechanism for controlling whether a field appears in the serialized representation. I would prefer to avoid making any static declarations (like what we do for CSV headers) as they're tedious to maintain. Simply ignoring fields prefaced with an underscore probably takes care of 80% of this. We can implement/tweak to_objectchange() on the remaining models to suppress any unwanted fields.

@jeremystretch commented on GitHub (Feb 21, 2020): We need to devise a robust mechanism for controlling whether a field appears in the serialized representation. I would prefer to avoid making any static declarations (like what we do for CSV headers) as they're tedious to maintain. Simply ignoring fields prefaced with an underscore probably takes care of 80% of this. We can implement/tweak `to_objectchange()` on the remaining models to suppress any unwanted fields.
adam commented 2025-12-29 18:28:26 +01:00
Author
Owner
Copy Link

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

We need to devise a robust mechanism for controlling whether a field appears in the serialized representation. I would prefer to avoid making any static declarations (like what we do for CSV headers) as they're tedious to maintain.

What about a hybrid, allows us to handle the MPTT case as that isn't captured by the underscore case.

@DanSheps commented on GitHub (Feb 21, 2020): > We need to devise a robust mechanism for controlling whether a field appears in the serialized representation. I would prefer to avoid making any static declarations (like what we do for CSV headers) as they're tedious to maintain. What about a hybrid, allows us to handle the MPTT case as that isn't captured by the underscore case.
adam commented 2025-12-29 18:28:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

I think it's reasonable to tackle that using a custom to_objectchange() method on the Region model.

@jeremystretch commented on GitHub (Feb 21, 2020): I think it's reasonable to tackle that using a custom `to_objectchange()` method on the Region model.
adam commented 2025-12-29 18:28:27 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Feb 24, 2020):

I see this was accepted. Anyone working on this or shall I?

I was gonna follow what Jeremy said and pop any fields prefixed with _ in ChangeLoggedModel.to_objectchange and override Region.to_objectchange to additionally remove the MPTT fields.

@hSaria commented on GitHub (Feb 24, 2020): I see this was accepted. Anyone working on this or shall I? I was gonna follow what Jeremy said and pop any fields prefixed with `_` in `ChangeLoggedModel.to_objectchange` and override `Region.to_objectchange` to additionally remove the MPTT fields.
adam commented 2025-12-29 18:28:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 25, 2020):

@hSaria feel free to take this one if you'd like.

@jeremystretch commented on GitHub (Feb 25, 2020): @hSaria feel free to take this one if you'd like.
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#3368
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?