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

Additional Features for Staged Changes #7334

New Issue
Closed
opened 2025-12-29 20:22:02 +01:00 by adam · 8 comments
adam commented 2025-12-29 20:22:02 +01:00
Owner
Copy Link

Originally created by @minitriga on GitHub (Dec 8, 2022).

NetBox version

v3.4

Feature type

Change to existing functionality

Proposed functionality

Below are some proposed changes to the Staged Changes functionality in Netbox 3.4 beta. Referencing #10851

  • When a branch changed has been merged the staged changed are deleted, I would like to be able to see that they are now applied_changes, this allows a user to go back and see branches that have been merged and see the changes that were applied.
  • I would like to propose the idea of a Branch status. When a branch has been created it in a Pending Merge state and after merge it is then moved into the Merged State.
  • I would like the ability to not show a model has been updated if only the last_updated column has been altered. I'm currently using Device.objects.update_or_create() to find and update a device using a serial number as a key, however when the data is the same it is causing the last_updated column to show the model has been updated.

Use case

This would assist plugin developers when making synchronisation plugins.

Database changes

Status Column on Branch Model

External dependencies

No response

Originally created by @minitriga on GitHub (Dec 8, 2022). ### NetBox version v3.4 ### Feature type Change to existing functionality ### Proposed functionality Below are some proposed changes to the Staged Changes functionality in Netbox 3.4 beta. Referencing #10851 - When a branch changed has been `merged` the staged changed are deleted, I would like to be able to see that they are now `applied_changes`, this allows a user to go back and see branches that have been merged and see the changes that were applied. - I would like to propose the idea of a Branch status. When a branch has been created it in a `Pending Merge` state and after merge it is then moved into the `Merged State`. - I would like the ability to not show a model has been `updated` if only the `last_updated` column has been altered. I'm currently using `Device.objects.update_or_create()` to find and update a device using a serial number as a key, however when the data is the same it is causing the `last_updated` column to show the model has been updated. ### Use case This would assist plugin developers when making synchronisation plugins. ### Database changes Status Column on Branch Model ### External dependencies _No response_
adam added the type: featurecomplexity: high labels 2025-12-29 20:22:02 +01:00
adam closed this issue 2025-12-29 20:22:02 +01:00
adam commented 2025-12-29 20:22:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 9, 2022):

When a branch changed has been merged the staged changed are deleted, I would like to be able to see that they are now applied_changes

We could retain the StagedChange instances, but would need some way to flag that each has been applied and prevent it from being re-applied.

I would like to propose the idea of a Branch status.

This seems to conflict with the first item. If we allow a branch to retain both applied and non-applied changes, the branch itself cannot have an atomic status. Or is the intent to only permit one type of change or the other? (If so, this would preclude a branch from being reused for successive merges.)

I would like the ability to not show a model has been updated if only the last_updated column has been altered.

Can you give an example of a change that causes this? Is it specifically related to staged changes, or just change logging in general?

@jeremystretch commented on GitHub (Dec 9, 2022): > When a branch changed has been merged the staged changed are deleted, I would like to be able to see that they are now applied_changes We could retain the StagedChange instances, but would need some way to flag that each has been applied and prevent it from being re-applied. > I would like to propose the idea of a Branch status. This seems to conflict with the first item. If we allow a branch to retain both applied and non-applied changes, the branch itself cannot have an atomic status. Or is the intent to only permit one type of change or the other? (If so, this would preclude a branch from being reused for successive merges.) > I would like the ability to not show a model has been updated if only the last_updated column has been altered. Can you give an example of a change that causes this? Is it specifically related to staged changes, or just change logging in general?
adam commented 2025-12-29 20:22:03 +01:00
Author
Owner
Copy Link

@minitriga commented on GitHub (Dec 13, 2022):

My issue is not with change logging but a StagedChange being created when only "last_updated" field has been updated. If the data is the same before and after only the "last_updated" field is changed causing a branch to show a change that is only updating that field causing false positives to show in the branch. Here is an example change that is trying to update an existing record:

If you run this within NB shell and then merge the branch you will have one new device. However if you run it again you will have a staged change with no changed fields except "last_updated".

from django.utils.text import slugify
from dcim.choices import DeviceStatusChoices
from extras.models import Branch
from netbox.staging import checkout
from datetime import datetime

device = {'configReg': None,
          'devType': 'fw',
          'domain': None,
          'family': 'asa',
          'fqdn': None,
          'hostname': 'L68ASAV5',
          'hostnameOriginal': None,
          'hostnameProcessed': None,
          'icon': None,
          'id': '36699432',
          'image': 'boot:/asa992-32-smp-k8.bin',
          'loginIp': '10.68.200.5',
          'loginType': 'ssh',
          'mac': '0200.6300.0524',
          'memoryTotalBytes': 2147483648,
          'memoryUsedBytes': 2147483648,
          'memoryUtilization': 100,
          'model': 'ASAv10',
          'objectId': None,
          'platform': 'asav',
          'processor': 'Pentium II 3333 MHz',
          'rd': None,
          'reload': None,
          'siteName': '68 Pardubice Distribution',
          'sn': '9AKRD59RU24',
          'snHw': '9AKRD59RU24',
          'stpDomain': None,
          'taskKey': '8cc1fd95-d3ed-4936-83b1-8b63d43c3dd9',
          'uptime': 8308800,
          'vendor': 'cisco',
          'version': '9.9(2)32'
          }

current_time = str(datetime.now())
branch = Branch.objects.create(name=f'{current_time}')
with checkout(branch):
    device_role, _ = DeviceRole.objects.get_or_create(
        name="Network Device", slug=slugify("Network Device"))
    site = Site.objects.filter(name=device['siteName'])[0]
    device_type = DeviceType.objects.filter(model=device['model'])[0]
    defaults = {
        "name": device['hostname'],
        "status": DeviceStatusChoices.STATUS_ACTIVE,
        'serial': device['sn'],
        'site': site,
        'device_type': device_type,
        'device_role': device_role
    }
    device_object, _ = Device.objects.update_or_create(serial=device['sn'], defaults=defaults)

In regards to the other points. I like the idea of keeping the StagedChange instances to see what has been applied maybe a status on that model (Boolean or Status Field). I have been using a Branch Instance for each set of changes. Once I have merged a branch I do not intend to go back and reuse the same branch for future staged changes but I guess the branch could be reused.

@minitriga commented on GitHub (Dec 13, 2022): My issue is not with change logging but a StagedChange being created when only "last_updated" field has been updated. If the data is the same before and after only the "last_updated" field is changed causing a branch to show a change that is only updating that field causing false positives to show in the branch. Here is an example change that is trying to update an existing record: If you run this within NB shell and then merge the branch you will have one new device. However if you run it again you will have a staged change with no changed fields except "last_updated". ```python from django.utils.text import slugify from dcim.choices import DeviceStatusChoices from extras.models import Branch from netbox.staging import checkout from datetime import datetime device = {'configReg': None, 'devType': 'fw', 'domain': None, 'family': 'asa', 'fqdn': None, 'hostname': 'L68ASAV5', 'hostnameOriginal': None, 'hostnameProcessed': None, 'icon': None, 'id': '36699432', 'image': 'boot:/asa992-32-smp-k8.bin', 'loginIp': '10.68.200.5', 'loginType': 'ssh', 'mac': '0200.6300.0524', 'memoryTotalBytes': 2147483648, 'memoryUsedBytes': 2147483648, 'memoryUtilization': 100, 'model': 'ASAv10', 'objectId': None, 'platform': 'asav', 'processor': 'Pentium II 3333 MHz', 'rd': None, 'reload': None, 'siteName': '68 Pardubice Distribution', 'sn': '9AKRD59RU24', 'snHw': '9AKRD59RU24', 'stpDomain': None, 'taskKey': '8cc1fd95-d3ed-4936-83b1-8b63d43c3dd9', 'uptime': 8308800, 'vendor': 'cisco', 'version': '9.9(2)32' } current_time = str(datetime.now()) branch = Branch.objects.create(name=f'{current_time}') with checkout(branch): device_role, _ = DeviceRole.objects.get_or_create( name="Network Device", slug=slugify("Network Device")) site = Site.objects.filter(name=device['siteName'])[0] device_type = DeviceType.objects.filter(model=device['model'])[0] defaults = { "name": device['hostname'], "status": DeviceStatusChoices.STATUS_ACTIVE, 'serial': device['sn'], 'site': site, 'device_type': device_type, 'device_role': device_role } device_object, _ = Device.objects.update_or_create(serial=device['sn'], defaults=defaults) ``` In regards to the other points. I like the idea of keeping the StagedChange instances to see what has been applied maybe a status on that model (Boolean or Status Field). I have been using a Branch Instance for each set of changes. Once I have merged a branch I do not intend to go back and reuse the same branch for future staged changes but I guess the branch could be reused.
adam commented 2025-12-29 20:22:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 5, 2023):

There's probably more to discuss here, and we'll likely break out some of the work to separate issues, but I've tagged this as needs milestone to ensure it remains a focus for future releases.

@jeremystretch commented on GitHub (Jan 5, 2023): There's probably more to discuss here, and we'll likely break out some of the work to separate issues, but I've tagged this as `needs milestone` to ensure it remains a focus for future releases.
adam commented 2025-12-29 20:22:04 +01:00
Author
Owner
Copy Link

@bkampsnl commented on GitHub (Jun 27, 2023):

I see this feature has the following use case :

This would assist plugin developers when making synchronisation plugins.

I am wondering : will it also be an idea to integrate this into the rest api / ui so that users can create branches in the web ui ?

So a user can make changes in netbox without directly saving them in the database but keeping the changes in a branch ? When the user is done he can verify if the changes can be committed to the database and then commit the changes.

I though I read in another issue that my desccribed use case is the final goal but the feature is broken down into smaller iterations. If so, I am wondering when will the rest api / web-ui part be developed ? Are there already ideas on how to implement this ?

I am really pleased with netbox, I think it's a great full feature application ! Respect to the very active developers ! I want to introduce it into my organisation and the branching / staging feature within the web-ui would make netbox even more great :)

I am a developer myself so if there are ideas on how to implement this in rest-api / web-ui maybe I can give a hand.

@bkampsnl commented on GitHub (Jun 27, 2023): I see this feature has the following use case : > This would assist plugin developers when making synchronisation plugins. I am wondering : will it also be an idea to integrate this into the rest api / ui so that users can create branches in the web ui ? So a user can make changes in netbox without directly saving them in the database but keeping the changes in a branch ? When the user is done he can verify if the changes can be committed to the database and then commit the changes. I though I read in another issue that my desccribed use case is the final goal but the feature is broken down into smaller iterations. If so, I am wondering when will the rest api / web-ui part be developed ? Are there already ideas on how to implement this ? I am really pleased with netbox, I think it's a great full feature application ! Respect to the very active developers ! I want to introduce it into my organisation and the branching / staging feature within the web-ui would make netbox even more great :) I am a developer myself so if there are ideas on how to implement this in rest-api / web-ui maybe I can give a hand.
adam commented 2025-12-29 20:22:04 +01:00
Author
Owner
Copy Link

@jadyndev commented on GitHub (Mar 19, 2024):

I see this feature has the following use case :

This would assist plugin developers when making synchronisation plugins.

I am wondering : will it also be an idea to integrate this into the rest api / ui so that users can create branches in the web ui ?

So a user can make changes in netbox without directly saving them in the database but keeping the changes in a branch ? When the user is done he can verify if the changes can be committed to the database and then commit the changes.

I though I read in another issue that my desccribed use case is the final goal but the feature is broken down into smaller iterations. If so, I am wondering when will the rest api / web-ui part be developed ? Are there already ideas on how to implement this ?

I am really pleased with netbox, I think it's a great full feature application ! Respect to the very active developers ! I want to introduce it into my organisation and the branching / staging feature within the web-ui would make netbox even more great :)

I am a developer myself so if there are ideas on how to implement this in rest-api / web-ui maybe I can give a hand.

From an OPs perspective it would be awesome to allow (external) workers to make changes within a branch (which could be auto-created for convenience) and let them submit their changes to an Admin/Reviewer for approval.

I'd suggest these changes to the permissions:

  • Add - Create or approve creation of new object
  • Change - Modify or approve modification(s) of an existing object
  • Delete - Delete or approve deletion of an existing object
  • Request Creation - Request creation of a new object
  • Request Change - Request change(s) to an existing object
  • Request Deletion - Request the deletion of an existing object

Maybe add a dropdown menu to switch between branches similar to GitHub?

@jadyndev commented on GitHub (Mar 19, 2024): > I see this feature has the following use case : > > > This would assist plugin developers when making synchronisation plugins. > > I am wondering : will it also be an idea to integrate this into the rest api / ui so that users can create branches in the web ui ? > > So a user can make changes in netbox without directly saving them in the database but keeping the changes in a branch ? When the user is done he can verify if the changes can be committed to the database and then commit the changes. > > I though I read in another issue that my desccribed use case is the final goal but the feature is broken down into smaller iterations. If so, I am wondering when will the rest api / web-ui part be developed ? Are there already ideas on how to implement this ? > > I am really pleased with netbox, I think it's a great full feature application ! Respect to the very active developers ! I want to introduce it into my organisation and the branching / staging feature within the web-ui would make netbox even more great :) > > I am a developer myself so if there are ideas on how to implement this in rest-api / web-ui maybe I can give a hand. From an OPs perspective it would be awesome to allow (external) workers to make changes within a branch (which could be auto-created for convenience) and let them submit their changes to an Admin/Reviewer for approval. I'd suggest these changes to the permissions: - Add - Create or approve creation of new object - Change - Modify or approve modification(s) of an existing object - Delete - Delete or approve deletion of an existing object - Request Creation - Request creation of a new object - Request Change - Request change(s) to an existing object - Request Deletion - Request the deletion of an existing object Maybe add a dropdown menu to switch between branches similar to GitHub?
adam commented 2025-12-29 20:22:04 +01:00
Author
Owner
Copy Link

@JoeIzzard commented on GitHub (Jun 18, 2024):

It would also be beneficial for our use case to be able to restrict who can see change branches. We have a lot of technicians that access Netbox to only see the current version and aren't interested in future projects.

A dropdown to change branches could then be hidden from users that don't have permission to view change branches. I do like the idea of a dropdown, maybe at the top of the sidebar under the Logo so it's easy to see your in a change context?

Mockup for context:
netbox-change-branch-dropdown

@JoeIzzard commented on GitHub (Jun 18, 2024): It would also be beneficial for our use case to be able to restrict who can see change branches. We have a lot of technicians that access Netbox to only see the current version and aren't interested in future projects. A dropdown to change branches could then be hidden from users that don't have permission to view change branches. I do like the idea of a dropdown, maybe at the top of the sidebar under the Logo so it's easy to see your in a change context? Mockup for context: ![netbox-change-branch-dropdown](https://github.com/netbox-community/netbox/assets/3457283/db75c0f7-e8bd-4f1c-8787-01fbabd615a9)
adam commented 2025-12-29 20:22:04 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Sep 17, 2024):

@jeremystretch I think we can close this, redundant now with branching?

@arthanson commented on GitHub (Sep 17, 2024): @jeremystretch I think we can close this, redundant now with branching?
adam commented 2025-12-29 20:22:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 17, 2024):

Yep; this functionality is now provided by the netbox-branching plugin. The legacy "staged changes" API in NetBox is being deprecated in v4.2 (see #17472) and will be removed in a future release.

@jeremystretch commented on GitHub (Sep 17, 2024): Yep; this functionality is now provided by the [netbox-branching plugin](https://github.com/netboxlabs/netbox-branching). The legacy "staged changes" API in NetBox is being deprecated in v4.2 (see #17472) and will be removed in a future release.
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 complexity: high 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#7334
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?