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

Pre-Change-Data missing on cascaded Deletions #4899

New Issue
Closed
opened 2025-12-29 19:21:54 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:21:54 +01:00
Owner
Copy Link

Originally created by @moonrail on GitHub (May 11, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v2.11.3

Python version

3.8

Steps to Reproduce

  1. Create a Device/VM
  2. Create a Journal-Entry on this Device/VM
  3. Create two Interfaces on this Device/VM
  4. Create a IP on the first Interface
  5. Delete the first Interface
  6. Look into Changelog (or API /extras/object-changes) and find, that the IP-Address-Entry will not have any "Pre-Change"-Data
  7. Delete the Device/VM
  8. Look into Changelog (or API /extras/object-changes) and find, that the Interface- and Journal-Entries will not have any "Pre-Change"-Data

Expected Behavior

Pre-Change-Data should be in the Changelog.

This is the case, if e.g. an IP-Address is deleted directly, but not when its deleted by a cascade.

Observed Behavior

Pre-Change-Data is missing in the Changelog, when an object is deleted by a cascade.

Originally created by @moonrail on GitHub (May 11, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v2.11.3 ### Python version 3.8 ### Steps to Reproduce 1. Create a Device/VM 2. Create a Journal-Entry on this Device/VM 3. Create two Interfaces on this Device/VM 4. Create a IP on the first Interface 5. Delete the first Interface 6. Look into Changelog (or API /extras/object-changes) and find, that the IP-Address-Entry will not have any "Pre-Change"-Data 7. Delete the Device/VM 8. Look into Changelog (or API /extras/object-changes) and find, that the Interface- and Journal-Entries will not have any "Pre-Change"-Data ### Expected Behavior Pre-Change-Data should be in the Changelog. This is the case, if e.g. an IP-Address is deleted directly, but not when its deleted by a cascade. ### Observed Behavior Pre-Change-Data is missing in the Changelog, when an object is deleted by a cascade.
adam added the type: bugstatus: accepted labels 2025-12-29 19:21:54 +01:00
adam closed this issue 2025-12-29 19:21:54 +01:00
adam commented 2025-12-29 19:21:55 +01:00
Author
Owner
Copy Link

@larsux commented on GitHub (May 11, 2021):

Hi,

the same bug is triggered, when (de-)selecting an IP as primary for a device (Make this the primary IP for the device/VM).
In the corresponding ChangeLog-Object for the Device/VM only the "Post-Change Data" is filled and "Pre-Change Data" is empty.

It seems that there are some 'snapshot' function calls missing before saving the device object.

@larsux commented on GitHub (May 11, 2021): Hi, the same bug is triggered, when (de-)selecting an IP as primary for a device (Make this the primary IP for the device/VM). In the corresponding ChangeLog-Object for the Device/VM only the "Post-Change Data" is filled and "Pre-Change Data" is empty. It seems that there are some 'snapshot' function calls missing before saving the device object.
adam commented 2025-12-29 19:21:55 +01:00
Author
Owner
Copy Link

@jweiher commented on GitHub (May 19, 2021):

Hi,

to me the way and locations where the snapshot method of the ChangeLogginMixin is called seems a bit odd. I think the reason why it is not working on related models is simply because it gets called in the views when fetching a single object and it does not know anything about related objects.
In my opinion it would be a better solution to wire the calling of the snapshot method somewhere in the models so all of the changelogging happens under the hood and is not scattered around the codebase.
just my 2 cents

-- Jan

@jweiher commented on GitHub (May 19, 2021): Hi, to me the way and locations where the snapshot method of the ChangeLogginMixin is called seems a bit odd. I think the reason why it is not working on related models is simply because it gets called in the views when fetching a single object and it does not know anything about related objects. In my opinion it would be a better solution to wire the calling of the snapshot method somewhere in the models so all of the changelogging happens under the hood and is not scattered around the codebase. just my 2 cents -- Jan
adam commented 2025-12-29 19:21:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 2, 2021):

Opting to put the call to snapshot() in the view was a performance optimization: We only want spend time taking a snapshot if we anticipate making changes to the model. For instance, we wouldn't want to take a snapshot of each instance in a list if we're just viewing a list of objects with no intent to modify them.

That said, maybe it's an unnecessary optimization. We could try calling it inside from_db() for each instance to ensure that a pre-change snapshot is always present, though testing is needed to determine the performance impact.

@jeremystretch commented on GitHub (Jun 2, 2021): Opting to put the call to `snapshot()` in the view was a performance optimization: We only want spend time taking a snapshot if we anticipate making changes to the model. For instance, we wouldn't want to take a snapshot of each instance in a list if we're just viewing a list of objects with no intent to modify them. That said, maybe it's an unnecessary optimization. We could try calling it inside `from_db()` for each instance to ensure that a pre-change snapshot is _always_ present, though testing is needed to determine the performance impact.
adam commented 2025-12-29 19:21:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 18, 2022):

A lot has changed since this bug was opened, but this seems solvable now by simply calling snapshot() in the pre_delete receiver.

@jeremystretch commented on GitHub (Nov 18, 2022): A lot has changed since this bug was opened, but this seems solvable now by simply calling `snapshot()` in the `pre_delete` receiver.
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: bug
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#4899
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?